Personal Agent、自进化与确定性—不确定性架构

引言：问题不是“模型够不够聪明”

Personal Agent 的难点，不只是让模型生成更好的答案，而是让一个具有不确定性的执行单元，在真实环境中持续完成任务、接受校验，并在出错后改进。更有用的工程问题是：哪些环节交给 Agent，哪些环节必须由确定性代码、规则和人工确认负责？

本文基于 2026-11-04 的随想素材，区分“素材中直接表达的观察”和“据此作出的工程化推论”，不把推论写成已验证事实。

传统函数通常有明确输入、固定逻辑和可预期输出；Agent 则会理解意图、选择工具、规划步骤，并根据环境反馈调整行为。同一目标可能得到不同路径，调用工具也可能失败。因此，不能把 Agent 当作一个“更大的函数”直接替换进旧程序。

更合理的组合方式是：让 Agent 处理需要理解、判断和规划的部分，让确定性程序处理结构化、可验证、不可出错的部分。例如，Agent 可以提出计划或抽取信息；代码负责格式校验、权限检查、状态机推进和结果落盘。两者交替组合，比单纯追求一个全能 Agent 更容易控制风险。

当 Agent 反复犯同一类错误时，继续增加提示词未必有效。可以改造它所处的环境：缩小可选动作范围，提供明确的工具契约，在关键节点加入校验和回读，把成功标准变成可观察的状态，并保留失败记录。

这意味着“让 Agent 变好”不一定等于训练一个更强的模型，也可以是改变任务分解、工具接口、反馈机制和权限边界。环境把隐含要求变成显式约束，能降低幻觉和误操作的代价。

多 Agent 的价值在于角色分工：不同 Agent 可以负责研究、写作、审核或执行，各自拥有更清晰的职责。但层级越多，协调成本、状态同步和责任追踪也越复杂。Super Agent 并不意味着一个无所不能的角色，更像是负责规划、分派、汇总和监督的协调层。

设计时应先问：这个角色是否有独立的上下文、权限或验收标准？如果没有，拆分可能只是增加通信开销。无论采用单 Agent 还是多 Agent，都需要明确谁启动任务、谁检查结果、谁有权推进状态，以及失败后如何回退。

“自进化”不能只理解为 Agent 自己总结几句话。可复用的改进至少应包含：记录失败现象和上下文；定位是提示、工具、流程还是环境问题；提出改动；在相同或相近案例上回归验证；确认改动没有引入新的错误；最后再把经验沉淀为规则、技能或测试。

如果没有指标和回归测试，所谓进化可能只是换一种说法重复失败。可观测的状态、可比较的结果和可重放的案例，是让不确定系统逐渐可靠的基础。

工作流擅长确定性的节点推进：任务进入、条件判断、权限校验和状态转换都可以被记录。Personal Agent 擅长在节点内部处理开放性工作。两者结合时，工作流负责边界与交账，Agent 负责节点内的探索和执行。

因此，“自主”不应等同于不受监督。更现实的定义是：Agent 能自主规划和启动一段工作，但必须在可观测、可暂停、可回滚的环境中运行，并在需要时把问题交还给人。人工审阅不是系统失败，而是高风险内容发布前必要的控制点。

Agent 工程的关键不是消灭不确定性，而是把不确定性放在适合它的位置：让它负责理解和探索，用确定性代码约束边界，用工作流记录状态，用指标和回归测试验证改进，用人工审阅守住高风险出口。

这条路线不承诺一次搭出完美的 Personal Agent。它提供的是一个可以逐步验证的工程闭环：观察问题，改造环境，组合 Agent 与确定性组件，测量结果，再根据证据迭代。本文强调在高风险出口保留人工审阅，发布前应完成必要的验证与授权。