No. 30: 我给悟空补了一个后台，才发现 Agent 最难的不是回答

悟空最早只有一个很直接的入口：我在 Telegram 里发消息，它理解需求、调用工具，再把结果发回来。只看演示，这条链路已经像一个完整的 Agent。

真正把它放进日常工作以后，问题才慢慢冒出来。任务超过几秒，它是在思考、执行还是卡住了？工具准备修改数据，我该在哪里确认？Telegram 没收到最终回复，是任务失败了，还是结果已经生成但投递失败了？

这些都不是回答质量问题。它们指向的是同一件事：消息框只能承载对话，承载不了一个持续运行、可能产生副作用的系统。

于是我给悟空补了一个 Dashboard。后来我才意识到，自己做的并不是普通后台，而是一层让 Agent 可见、可控、可恢复的操作面。

一条回复背后，已经出现了很多看不见的状态

一次短问答可以被压缩成「输入和输出」。但只要任务变长，中间就会出现 Run、Step、工具调用、审批、重试、恢复和消息投递。

如果这些状态只存在于程序内部，用户看到的体验就只剩下两种：有回复，或者没有回复。前者看起来一切正常，后者却无法判断到底发生了什么。

所以悟空现在会把长任务的进度维护在同一条 Telegram 消息里。短任务不额外打扰，超过时间阈值后才持续更新；任务完成后，最终结果仍然回到原来的对话。这里的重点不是多发几条提示，而是把「系统还活着、正在做什么、下一步可能发生什么」翻译成用户可以理解的反馈。

Dashboard 则承担消息框放不下的部分：运行到了哪一步、哪次工具调用在等待确认、哪个投递需要重试，以及一次恢复应该从哪里继续。

生成了结果，不等于用户已经收到结果

我以前很容易把任务状态写成成功或失败。后来才发现，这种二元状态会隐藏一个重要断层：Agent 可能已经完成任务，但 Telegram 的最终消息还没有送达。

如果系统在这个时候直接标记完成，用户看到的是沉默；如果盲目重跑整个任务，又可能重复调用工具、重复写入数据，甚至产生第二份不一致的结果。

悟空因此把运行完成与消息投递分开记录。最终回复先进入 Outbox，再以幂等方式投递。只有 Run 和投递状态都收敛，用户视角下的任务才真正结束。

这让我重新理解了 Agent 的「完成」：它不是模型已经给出答案，也不是后端函数已经返回，而是承诺的结果已经抵达用户可以使用的位置。

长任务必须允许暂停、取消和接管

当 Agent 只回答问题时，停止生成已经足够。可一旦它开始访问文件、调用外部服务或执行多步任务，用户就需要更细的控制权。

悟空为运行中的任务补上了查询、暂停、取消、接管和修订。它们不是后台里摆着好看的按钮，而是不同的状态契约：暂停后哪些步骤不能继续，取消是否保留已有产物，接管以后自动执行权交给谁，修订从哪一条新指令重新规划。

这里最容易犯的错误，是把按钮点击等同于操作完成。真正可靠的控制需要落到运行状态、执行器和恢复路径上，并留下可以核对的证据。否则用户点了「取消」，后台仍然继续调用工具，界面上的控制只是一种安慰。

工具越有用，权限边界越不能只靠模型判断

Agent 的能力来自工具，风险也来自工具。读取天气和删除文件显然不该共享同一套授权方式；同一个工具，在不同参数和作用范围下，风险也可能完全不同。

悟空把 MCP 工具暴露的风险说明当作参考信息，而不是最终裁决。真正的边界仍然由本地策略、能力授权和用户确认共同决定。高风险动作必须在执行前展示影响范围，并由用户做最终确认。

这层设计看起来比「让模型自己判断是否安全」麻烦，但它守住了一个基本事实：模型可以提出行动，不能替用户扩张权限。Dashboard 的 Capabilities 和 Governance 页面，正是用来解释哪些能力已经授予、哪些操作被拦截，以及下一步需要谁做决定。

后台不是数据仓库，而是用户的决策路径

最初做 Dashboard 时，我也会自然地想到日志列表、运行表格和一排状态卡片。但把内部对象全部展示出来，并不会自动带来可理解性。

我最后把页面收敛成几条真实决策路径：Operations 看正在发生什么，Diagnostics 解释为什么失败，Data 处理数据和投影问题，Capabilities 管理工具能力，Governance 处理权限与审计。

每个页面都应该回答三个问题：发生了什么，对我有什么影响，我现在可以做什么。没有下一步动作的指标，只是开发者的观察数据，不一定值得成为用户界面。

同样，后台也不应该为了「可观测」暴露所有隐私内容。悟空只展示必要的状态和证据，不默认展开对话正文、工具参数与完整返回值。可解释不等于无限制透明，操作面本身也需要最小披露。

事实源和可修复投影必须分开

悟空使用 MongoDB 保存运行、消息和记忆事实，Chroma 承担向量检索。两者看起来都在保存数据，但职责完全不同：前者是事实源，后者只是可以重建的投影。

这个区别决定了修复方式。向量投影出现漂移时，可以先 dry-run，备份后再按精确范围修复；修复不能反过来改写 MongoDB 里的事实。自动记忆也不能因为模型觉得「可能有用」就写入，必须能从当前用户消息中找到证据。

如果不区分事实与投影，一次索引修复就可能变成数据篡改，一次模型推断也可能沉淀成用户从未说过的长期记忆。Dashboard 在这里承担的不是数据库管理，而是把数据边界、漂移证据和修复影响讲清楚。

我现在如何判断一个 Agent 能不能进入日常使用

这轮改造没有让悟空回答得更像人，却让它更接近一个可以长期使用的系统。我不再只看模型效果，而会继续追问：长任务有没有进度，副作用是否需要确认，失败后能否恢复，结果是否可靠送达，用户能否随时收回控制权。

这些能力不适合做成演示里的高光时刻，却决定了 Agent 是一次性的聊天玩具，还是可以真正托付工作的个人基础设施。

一个 Agent 真正进入日常使用，不只要会回答，还要让人随时知道它正在做什么、能不能停、出了问题从哪里继续。

项目：Wukong

← Writing