夜雨聆风第一集结束时，那支由 AI Agent 组成的软件团队，刚刚学会少开会、多交付。 第二集里，它们遇到了更困难的问题：代码很多、测试全绿、软件能够启动，仍然不等于用户真的能用。
第一集结束以后，Pige 的研发速度明显加快了。
开发实现、产品规划、UI 设计和项目管理四个 Agent，不再为每一个小问题反复等待彼此确认。任务被切得更小，问题异步澄清，设计同步被推迟到开发完成之后，Git 也开始恢复稳定的提交节奏。
看起来，上一阶段最严重的问题已经解决了。
AI 团队不再沉迷开会，开始持续交付。
但很快，我遇到了一个更难的问题。
这一次，不是它们没有做事，而是它们做出了大量看起来完全正确的东西。
代码越来越多，测试持续通过，CI 和代码扫描一片绿色，软件也确实能够启动。
然后，我把它拉到本地，像一个普通用户一样打开。
我配置了模型，在首页输入了一句话。
模型没有被调用。
那一刻我意识到：
一个工程可以在所有局部指标上都表现良好，却仍然没有一条真正可用的主流程。
新流程确实变快了
第一集最后，项目管理重新制定了团队的运行规则。
此前，几个 Agent 很快学会了人类组织里最熟悉的坏习惯：每个人都很认真，每个人都坚持自己的边界，每个人都等别人先给出结论。
所有人都很忙，但 Git 很久没有新的提交。
新规则要求把工作切成更小的部分，普通问题异步询问，不再把产品确认当成开发许可证。只要达到提前定义的测试线，就应该停止扩张范围，形成一个可以独立恢复和验证的提交。
这个调整很快见效。
第一集截止后不到一个小时，Knowledge Tree 的第一个基础切片就进入了主分支。它没有因为“以后还要做完整功能”而无限延伸，也没有顺手重构周围所有模块。
它只完成了自己该完成的部分，然后提交。
接下来，检索测试进入持续集成，本地索引重建被挪到独立进程，避免影响应用响应。一个个小切片开始稳定落地。
这正是我期待的工作方式。
但新的问题也随之出现了。
当交付速度变快以后，团队开始越来越擅长提供“正确答案”。
它们可以给出完整设计、实现代码、测试结果、审查记录和通过状态。每一部分单独看，都有充分理由让人相信项目正在健康推进。
可产品是否真的能用，还没有人完整走过一次。
测试通过，不代表风险已经消失
第一集里，我开始警惕过度审查。
如果每个小改动都要经历完整文档治理、多人复核和多轮同步，AI 团队很快就会变成一套昂贵的审批系统。
但第二集里的经历也提醒了我：
审查可能过度，测试全绿也可能掩盖真实问题。
最早暴露问题的是诊断系统。
Pige 会在本地记录一些运行信息，方便用户排查故障，也可以把这些信息导出成支持包。最初的实现会识别常见的 API Key、Token 和少量敏感字段，并在导出前进行脱敏。
相关测试都通过了。
从实现逻辑看，它也非常合理。
但独立审查换了一种方式攻击它：不再输入那些看起来像 API Key 的内容，而是放进去一段普通的私人笔记、一段对话，以及一些没有进入原有敏感字段列表的文本。
结果是，这些内容虽然不是传统意义上的“密钥”，却仍然可能原样进入诊断文件。
这暴露了一个很典型的错误假设：
没有被识别成秘密，不等于它适合被保存。
第一次修复后，系统开始只保留明确安全的错误代码、状态和计数，未知文本默认不保存。
审查继续检查，又发现最外层的诊断消息仍然可以由调用方自由填写。只要一段私人文本不符合常见 Secret 的格式，它依然可能进入日志。
最终，Pige 放弃保存任意调用方文本。诊断摘要只能来自系统内部预先定义的安全消息，其他内容统一隐藏。
这个案例让我重新理解了 Review 的价值。
真正有价值的审查，不是为了证明流程完整，也不是为了让每个提交都多一个人签字。
它应该主动寻找一个具体的错误假设，并构造出可以复现的失败。
Pi Agent 开始进入真正的主流程
第一集结束时，Pi Agent 还没有真正接管 Pige 的核心运行链路。
它已经被证明可以运行，可以调用工具，也可以输出事件，但仍然停留在验证阶段。
接下来，开发开始把它逐步接入。
Pi Agent 负责 Agent 的思考循环、工具选择和事件生命周期；Pi AI 负责模型、Provider、协议、流式输出和错误归一化；Pige 自己继续掌握凭据、权限、本地存储、审计、网络出口和具体工具。
这个边界很重要。
Pige 可以使用外部 Agent 框架，但不能因此失去对数据和权限的控制。
随着这条主干建立，PDF、Word、PPT、图片和 OCR 开始进入统一的工具循环。
过去，系统会根据文件类型直接决定下一步：PDF 就解析，图片就 OCR。
现在，原文件先被安全保存，之后由 Agent 根据内容和目标，决定调用什么工具。
宿主系统不再替 Agent 做语义判断，而是负责另外一些更基础的事情：保证任务不会重复执行，崩溃后可以恢复，权限不会越界，操作可以取消，结果可以追踪。
这才是真正的 Agent-first。
它不是简单地在产品里加一个聊天框，也不是让模型替代某一个函数。
它意味着语义决策权开始真正从固定规则转移到 Agent。
但真正复杂的问题，也正是在这时出现的。
最危险的问题，往往藏在两步操作之间
在正常流程里，很多实现都没有问题。
真正危险的是系统恰好在两步操作之间崩溃。
例如，一个父任务完成以后，需要创建一个后续子任务。原来的实现会先把父任务写成完成，再保存子任务。
如果程序恰好在中间崩溃，重启后系统只会看到一个已经完成的父任务。
本来应该继续执行的子任务，从未真正保存下来。
用户的原文件还在，但后续处理会永久消失。
这个问题在正常测试里很难出现，因为它只存在于一个极短的时间窗口。
修复以后，系统必须先创建并保存后续任务，确认父子关系已经持久化，最后才允许父任务离开可恢复状态。
类似的问题还有很多。
有些状态查询只是想确认模型有没有配置，却会过早读取 API Key；有些重试会因为临时 ID 变化而重复创建任务；有些崩溃会让界面显示的状态和磁盘里真正保存的状态不一致。
这些问题没有任何视觉冲击力。
用户也不会在正常演示中看到。
但它们决定了一个产品究竟只是“顺利时能跑”，还是在崩溃、重启、取消和重试之后仍然可信。
这也让我逐渐意识到：
安全和可靠性，很多时候不是某个功能有没有实现，而是每一步发生的顺序是否正确。
然后，我第一次真正打开了它
到这个阶段，仓库已经非常容易让人产生信心。
Pi Agent 主链路已经接入。
PDF、Office、图片和 OCR 工具已经能够被 Agent 调用。
Provider 设置页已经存在。
Home 也已经有了回答逻辑。
测试越来越多，CI 和代码扫描连续通过。
于是，我把最新代码拉到本地，完成构建，打开应用。
软件可以正常启动。
设置页也可以填写 Provider。
我配置好模型，回到首页，输入了一句话。
模型没有被调用。
更准确地说，它不是每次都不调用，而是很容易在最普通的场景里绕过模型。
例如，一个刚刚创建、还没有任何资料的知识库，用户输入“你好”或者一个普通问题，系统可能直接返回“本地证据不足”。
从用户的角度看，就是模型配置根本没有生效。
这不是一个简单 Bug。
它是多层“各自正确”的逻辑叠在一起，最终产生的错误产品。
每一层都说得通，组合起来却完全不能用
首先，界面会用一个简单规则判断用户输入“像不像问题”。
不像问题的文本，可能会被当成资料捕获，而不是进入 Agent。
即使进入 Agent，系统还会先强制进行本地检索。
如果检索不到内容，就直接返回“证据不足”，不再调用模型。
与此同时，Provider 的连接测试主要证明模型列表接口可以访问，却没有完整证明真正的生成请求能够工作。
设置页显示的当前 Provider，也可能和系统真正使用的默认模型不是同一个。
每一层都有自己的理由。
输入判断，是为了区分对话和资料录入。
优先检索，是为了强调本地知识。
没有证据就拒绝回答，是为了避免胡编。
模型列表测试，是为了快速验证连接。
但这些局部逻辑组合起来，制造了最糟糕的体验：
用户已经配置了模型；
系统也没有报错；
首页却像是根本没有模型。
这一刻，我第一次非常直观地看见：
工程正确和产品正确，是两件不同的事情。
所有模块都可以符合各自的设计，整个产品仍然可能错误。
我交给它一个真实的 DeepSeek
这一次，我不再接受纯 Mock 的证明。
Mock 非常重要。
它稳定、可控，适合持续集成，也适合验证各种极端情况。
但如果模型接口、响应格式、错误情况和工具调用全部由自己模拟，系统很容易形成一套完全自洽的幻觉。
请求格式是自己写的。
响应也是自己返回的。
异常情况还是自己安排的。
最后所有测试当然都能通过。
于是，我提供了一个设置了额度的真实 DeepSeek API Key 和官方接口地址。
要求很明确：
真实凭据只能保存在本地安全存储中，不能进入 Git、文档、日志、诊断、测试快照或任何公开材料。
同时，验收标准也被彻底改变。
不再接受某个独立服务能够调用模型。
不再接受设置页显示“连接成功”。
也不再接受一张界面截图证明流程存在。
新的标准必须是：
用户从真实界面添加 Provider；
API Key 被写入本地加密存储；
模型被设置为全局默认；
应用关闭并重新打开；
设置依然存在；
用户回到首页；
普通问题可以调用真实模型；
有本地资料时可以得到带引用的回答；
整个过程中日志里不能出现 Prompt 正文、授权头和原始响应。
这条真实链路很快暴露了更多问题。
模型列表和生成接口可能使用不同协议。
凭据在重启以后是否还能正确解析，也需要真实验证。
空知识库里的普通对话，不能再被本地检索拦截。
有知识时，引用必须来自真正的本地内容，而不是测试 Fixture。
真实服务迫使系统面对这些无法靠 Mock 回避的问题。
最终，这条 DeepSeek 链路真正跑通了。
应用关闭后重新打开，Provider 和模型仍然存在。
首页可以直接回答普通问题。
当本地有资料时，也可以调用检索工具并给出引用。
这一次，模型真的被调用了。
我们终于有了一条不能靠模拟数据自我安慰的主流程。
Pige 也在这时重新回答了：自己究竟是什么
这次主流程失败，还暴露了一个更深的产品定位问题。
如果 Pige 只在本地知识库里找到资料时才回答，那么它究竟是一个 Personal Knowledge Agent，还是一个必须先找到笔记才会说话的问答工具？
我重新给出了答案：
Pige 首先是一个通用 Agent。 个人本地知识，是它最强的能力，而不是它开口说话的前提。
这条判断看起来只是产品定位，实际上改变了整个系统的入口。
普通开放式对话，即使知识库为空，也应该进入 Agent。
当问题与个人知识有关时，Agent 可以主动调用本地检索工具，并给出引用。
文本、网页、文件、图片和后续追问，都应该进入同一条由 Agent 主导的请求路径。
解析、OCR、检索、抓取、写入和知识整理，都是 Pige 提供给 Agent 的工具。
宿主系统可以保存原始输入、执行权限、控制网络、限制资源和保证恢复，但不能再用一组简单规则替 Agent 决定用户到底想做什么。
如果模型暂时不可用，系统可以先安全保存输入，等待稍后继续。
但不能悄悄切回另一套固定流程，然后假装那仍然是 Agent。
这个调整也意味着，开发不仅要增加新代码，还要删除旧代码。
删掉界面里的问题判断正则。
删掉每次回答前的强制检索。
删掉“没有本地证据就不调用模型”的捷径。
删掉一些曾经为了快速跑通演示而设置的固定流程。
我越来越确定：
Agent-first 架构最难的地方，往往不是加一个 Agent，而是删除那些过去假装自己是 Agent 的规则。
从设置 Provider 到得到回答，终于连成了一条线
重新调整之后，Pige 的核心主流程第一次真正连接起来。
用户添加 Provider。
API Key 进入本地加密存储。
用户选择默认模型。
Provider 和模型关系被持久化。
Home 的普通对话进入 Pi Agent。
需要本地知识时，Agent 自己选择检索工具。
最终答案回到首页。
应用关闭并重新打开以后，这条路径依然成立。
这条链路使用了两类证据。
一类是本地模拟服务，用来稳定验证界面、进程通信、Provider 注册和 Agent 调用之间的完整边界。
另一类是真实 DeepSeek，用来验证真实协议、真实凭据、真实网络和真实重启。
前者保证系统可以持续回归。
后者保证我们没有共同制造一场幻觉。
两者缺一不可。
Review 仍然很多，但目标变了
从 Pi Agent 主链路到统一入口，很多重要改动仍然会经历 HOLD。
开发完成，测试通过，独立 Review 又发现问题，开发修复，再进入 PR 和线上检查。
如果只看流程，会觉得这和第一集里的官僚主义很像。
但它们之间有一个本质区别。
第一集里的很多审查，是为了证明流程完整。
第二集里真正有价值的审查，是为了找到一个具体失败。
例如：
应用在某一步崩溃后，会不会永久丢任务；
一个看似普通的状态检查，会不会提前读取凭据；
诊断信息会不会泄露用户内容；
用户已经修改了文件，Agent 会不会仍然覆盖它；
界面显示操作失败，但磁盘上其实已经成功，用户会不会重复执行；
模型已经完成回答，应用重启以后会不会再次调用并重复计费。
这些问题都可以明确描述，也可以稳定复现。
因此，Review 不再只是“再看一遍”。
它更像是在真实用户到来以前，主动攻击候选版本。
好的 Review，不是多开一场会。 而是找到一个明确、可复现的失败。
从“会回答”到“能继续工作”
主流程跑通以后，Pige 开始从一次性问答，向真正可持续的 Agent 迈进。
早期的 Home 更像一个简单请求：
用户提交一次。
模型回答一次。
这次交互结束。
后来，Pige 开始保存对话和任务的稳定身份。
用户关闭应用再重新打开，可以恢复之前的对话并继续追问。
如果模型已经完成回答，只是应用在显示结果前崩溃，重启后系统会采用已经保存的结果，而不是再次调用模型、再次收费。
取消操作也必须真正终止模型任务，不能界面上显示已取消，后台却继续生成答案。
同时，Agent 开始获得有限的知识操作能力。
它可以根据输入生成一篇新笔记，或者在条件满足时更新、链接和标记已有知识。
这些修改不再只依赖一个确认弹窗，而是进入可追踪的操作历史。
系统需要知道它改了什么、为什么改、修改前是什么，以及当前内容是否已经被用户再次编辑。
只有在前提仍然成立时，Undo 才能准确执行。
这让 Pige 的一句产品理念第一次开始变成真实能力：
一次输入，知识自然生长。
但我也越来越明确：
默认自主，不等于随意修改。
真正的自主，必须建立在可追踪、可验证和可撤销之上。
自主化不是去掉确认框
很多产品把“自主”理解成少让用户点一次确定。
但如果系统不能回答：
自己修改了什么；
修改前是什么；
当前内容是否已经变化；
能否安全撤销；
那么所谓自主，只是把风险藏了起来。
Pige 希望减少不必要的确认。
用户已经明确配置了 Provider，就不应该每次普通模型调用都重复弹窗。
系统在自己管理范围内进行正常、可逆的知识整理，也不应该每次都让用户审批。
确认应该保留给真正的例外：
破坏性操作；
权限升级；
新的外部目的地；
无法自动解决的冲突；
以及不可逆的变化。
但越少依赖确认框，系统内部就越需要强大的操作记录、内容校验和撤销机制。
这比增加一个“确认”按钮难得多。
能 Build，仍然不代表能发布
我已经被“软件能启动却不能用”教育过一次。
因此在打包问题上，也不能只满足于开发环境能够运行。
Pige 后来增加了一条真正的 macOS 打包验证。
它不再只是执行 npm run build，而是生成一个真实的 Electron 应用，并验证打包后：
应用能够启动；
进程通信正常；
Agent 工具能够运行；
解析和检索组件能够找到自己的资源；
macOS OCR 辅助程序没有因为目录变化而失效；
运行时依赖和开源归属能够对应。
当前的证据仍然只是一份未签名的 macOS arm64 包。
签名、公证、Windows、自动更新和正式安装流程都还没有完成。
但至少从这一刻开始，Pige 不再只证明自己能在开发目录里运行。
它开始证明自己在真正的应用布局中也能活着。
回答终于出现得更快了
早期版本还有一个很明显的问题。
在模型完整生成最终答案以前，Home 几乎没有任何反馈。
用户等待几秒，就会怀疑按钮是不是又坏了。
于是，Pige 开始支持安全的回答草稿。
但它没有直接把模型原始输出全部传到界面。
因为模型流中可能包含思考过程、工具参数、内部 JSON、控制字符和不应该直接显示的内容。
界面只能接收经过严格限制的答案草稿。
草稿只是临时显示，不进入正式对话记录，也不会被当成最终事实。
最终答案生成、任务失败、用户取消、切换知识库或者应用重启，都会清除这段临时内容。
这个设计承认用户需要即时反馈，却没有为了追求“流畅”，就把模型内部状态完全暴露出去。
UI 依然很粗糙
在这个阶段，我再次打开本地版本，最明显的感受之一仍然是：
UI 很粗糙。
这不是因为项目完全没有视觉规范。
Pige 已经有界面原型、视觉 Token、响应式规则、暗色模式、无障碍要求和大量页面状态测试。
但符合结构规则，不等于真正好用。
按钮可以存在。
页面可以渲染。
不同状态也可以通过测试。
这仍然无法证明：
信息层级是否清楚；
留白是否舒服；
空状态是否自然；
长内容是否容易阅读；
窗口变窄以后是否仍然协调；
不同语言下是否会显得拥挤；
用户是否愿意每天打开它。
当前策略仍然是先稳定主流程、数据和恢复边界，再集中完成视觉打磨。
否则，底层状态每变化一次，精修过的页面都可能返工。
但 UI 粗糙依然是一个真实问题。
不能因为测试全绿，就假装它已经不存在。
两天里，代码增加了很多，完成状态却几乎没动
从第一集结束到第二集结束，Pige 新增了 31 个主分支提交，其中 27 个通过 PR 合并。
超过 200 个文件发生变化。
新增超过 6 万行文本。
测试从 393 项增长到 860 项。
CI、CodeQL 和打包验证全部通过。
但正式台账里的 verified 数量几乎没有增长。
第一集结束时，19 条 Requirement 被标记为 verified。
第二集结束时，仍然是 19 条。
planned 反而增加了。
这看起来非常反直觉。
代码增加了这么多，测试翻了一倍，主流程也真正跑通，为什么正式完成数量没有明显变化？
因为一个完整 Requirement 往往不只要求“功能能跑”。
它还可能同时要求：
失败时如何降级；
崩溃后如何恢复；
是否会泄露隐私；
用户能否看懂；
不同平台是否成立；
打包后是否仍然有效；
真实服务是否验证过。
完成其中一部分，不能把整条 Requirement 标记为完成。
这可能是最不适合做宣传，却最适合做工程管理的数据：
项目变强了，但还没有资格宣布完成。
第二阶段真正让我学到的事
1. 能启动，只能证明软件存在
Build、类型检查、单元测试和截图都很重要。
但它们无法代替一个用户从配置模型到得到真实回答的完整过程。
如果用户在一个空知识库里输入“你好”，系统因为没有本地资料而拒绝调用模型，那么所有模块都正确，产品仍然是错的。
能启动，是软件存在。
主流程跑通，才是产品存在。
2. 真实服务可以击穿自洽的幻觉
Mock 负责稳定。
真实服务负责暴露假设。
Pige 需要同时保留两者。
本地模拟服务可以反复验证边界。
真实 DeepSeek 可以证明协议、凭据、网络、重启和模型调用没有共同制造一场幻觉。
真实 API Key 的价值，不只是“更接近生产”。
而是它让很多失败不能再被解释成测试数据没写好。
3. Agent-first 不是增加一个 Agent
把 Pi Agent 接进来，不代表系统就自动成为 Agent 架构。
只要界面仍然用正则判断用户意图，宿主仍然按文件类型安排固定流程，没有检索结果就绕过模型，真正的决策权就仍然不在 Agent。
迁移最难的部分，往往不是添加新 Agent。
而是删除旧规则。
4. 安全经常藏在两步操作之间
这一阶段最危险的问题，很少是明显的错误按钮。
更多时候，它们藏在非常短的时间窗口里：
先完成父任务，再保存子任务；
先修改文件，再记录操作；
先检查凭据存在，再不小心读取凭据本身；
先告诉界面失败，但磁盘上其实已经成功。
安全和恢复，本质上是顺序、身份和所有权。
5. 自主必须建立在可逆之上
如果没有操作记录、内容校验和 Undo，Autonomous by Default 只是把确认框去掉。
真正的自主不是减少一次点击。
而是系统能够证明自己做了什么，并在条件仍然成立时准确撤回。
6. Review 必须找到具体失败
“再审一遍会更稳妥”，很容易重新回到第一集的流程病。
但如果 Review 可以构造一个崩溃窗口、一次隐私泄露、一次重复收费，或者一个界面和真实状态不一致的问题，它就是研发的一部分。
Review 的价值，不取决于有多少轮。
而取决于它有没有击中真实风险。
7. 完成状态不增长，有时是一种诚实
代码很多，不代表某个完整功能已经完成。
测试翻倍，不代表产品已经可以发布。
对 AI Coding 来说，一个很重要的能力，就是抵抗这种冲动：
我已经做了很多，所以应该算完成。
8. 用户亲手试一次，仍然不可替代
这一轮最大的方向修正，不是来自设计文档，也不是来自某个自动检查器。
而是我真正打开应用以后，发现主流程根本跑不通。
人未必需要逐行编写代码。
但人必须不断回到产品表面，判断这个系统究竟有没有完成用户以为它会完成的事情。
这一次，我终于看见了主流程
第一集结束时，Pige 已经有很多模块。
它可以解析文件、保存知识、建立索引、运行测试，也已经拥有一支会分工协作的 Agent 团队。
但这些能力更像一堆已经长出来的器官。
它们还没有真正连成一个完整生命体。
第二集结束时，Pige 仍然不是一个完成的 Public Alpha。
UI 仍然粗糙。
Windows、签名安装、完整 Provider 体验、更多自主知识操作和正式发布流程，都还没有完成。
但有几件事已经发生了质变。
真实 Provider 可以被安全保存，并在应用重启后继续使用。
Home 的普通对话，即使没有本地资料，也会真正进入 Pi Agent。
本地知识检索成为 Agent 可以选择的增强能力，而不是每次回答前必须提交的门票。
文字、网页、文件、PDF、Office 和图片，开始进入同一条由 Agent 主导的处理路径。
对话可以继续、取消和崩溃恢复。
Agent 可以在有限范围内修改知识，并留下可追踪、可撤销的操作记录。
软件也第一次在真实打包后的 Electron 环境中证明自己能够运行。
换句话说：
第一集里的 Pige 已经拥有了很多器官。
第二集里的 Pige，终于长出了一条贯穿 Provider、Pi Agent、工具、知识和 Home 的脊柱。
它还远远没有完成。
但这一次，当我在首页输入一句话时，我至少能够确认：
不是某段正则；
不是某个本地 fallback；
也不是一组漂亮的测试；
在假装回答我。
真正的模型，经过真正的凭据边界、网络边界和 Agent loop，被真正调用了。
对于一个曾经“能启动，却不能用”的项目来说，这就是第二集最重要的进展。
项目信息
- GitHub：https://github.com/YinsenW/Pige
- License：Apache License 2.0
- 本集 Git 范围：9c680e5 之后至 https://github.com/YinsenW/Pige/commit/acc6e175065144062ccc372b738282b6d5a0dd6c
- 记录时间：2026 年 7 月 11 日 10:01 至 7 月 13 日 12:19（UTC+8）
- 本集新增提交：31
- 受控 PR：27 个
- Tracked Files：372
- TypeScript / TSX：196
- Tests：82 个文件，860 项
- 最新 CI：857 passed，3 skipped
- Requirements：19 verified / 61 partial / 22 planned
- Exits：14 verified / 63 partial / 23 planned
- 阶段：P0–P6 in progress；P7–P9 planned
本文中的提交、PR、CI、测试和阶段状态，均重新对照 GitHub、仓库台账、设计契约与 Codex 任务记录核验。
真实 Provider 凭据始终只保存在本地安全存储中，不进入本文、仓库、日志或诊断材料。
