返回 TraceWise 项目总览 · 交互图：产品 · 运行时 · 架构 / 端到端 · 工作流
当代码中出现 Planner、Worker、Verifier、Synthesizer 和 Persona，人们很容易把系统描述成“多个 Agent 自治协作”。这个说法听起来先进，也很适合演示，但名称不能代替控制流。
TraceWise 曾经面临同样的问题。项目确实使用了这些责任名称，前端也展示“子图责任段”和“Verifier 缺口”。但沿着一次真实请求往下看，当前实现是一个进程内、同步、确定顺序的分析流水线。它有清晰的责任划分，却没有独立 Agent 所需的调度、持久化、预算和故障恢复边界。
这篇文章沿调用路径解释：Planner、Verifier 和 Persona 分别处理什么输入，如何传递结果，在哪里作出判断。
先看真实控制流
一次子图编排由同一个 SubgraphOrchestratorService 顺序执行：
Planner → 根据问题、选中节点和显式上下文规划子图 Dispatcher → 记录 worker_count，明确 execution=sequential Subgraph Worker → 在 for 循环中逐个分析子图 Verifier → 汇总 Evidence、缺口和启发式差异 Synthesizer → 组织最终文本与建议动作
执行记录使用 planning、delegation、worker、verification、synthesis 等 stage，并给每个阶段标注 actor。这个记录让责任段可观察，但 actor 名称没有改变它们共用同一服务实例、同一调用栈和同一运行生命周期的事实。
技术解释图：产品运行时包含多个责任明确的服务，但图中的责任名称不等于多个自治 Agent。
Planner 做的是有界分解
Planner 根据问题搜索种子节点，将显式选中的节点固定进入候选，再按邻域、关系权重、跳数和上限形成若干子图。Preview 阶段可以先把这些责任段展示给用户，而不直接执行分析。
Planner 当前不具备：
- 自己的长期记忆；
- 独立模型会话；
- 可持续运行的任务队列；
- 动态创建或终止其他 Agent 的能力；
- 独立重试与恢复策略。
因此更准确的说法是“问题引导的子图规划责任段”。
Worker 是顺序执行，不是并行群体
编排器对规划出的子图做一个普通 for 循环，每次调用 _analyze_subgraph，然后记录 claim 数、Evidence 数和 confidence。运行快照甚至明确写入 execution: sequential。
这种设计并不低级。相反，它带来三个现实好处：
- 输出顺序稳定，便于复现和测试；
- 共享 Graph 快照时，不必处理多个 Worker 的版本竞争；
- 失败点集中，用户能知道在哪个责任段中断。
代价也很明确：它没有并行吞吐，也没有独立 Worker 的取消、隔离和部分恢复。如果未来把 Worker 变成真正的独立执行单元，必须重新定义输入快照、预算、幂等、超时、取消和聚合契约，而不是简单把 for 循环改成并发调用。
Verifier 验证的是缺口，不是结论真伪
当前 Verifier 汇总两类信号：
- 哪些子图节点没有 Evidence；
- 不同子图的启发式 confidence 是否出现明显差异。
它还会把这些问题转换成 conflicts 和 suggested actions。例如，存在缺失 Evidence 时要求补充依据；出现置信差异时建议人工比较责任段。
这是一种有用的结构检查，却不能被描述为“Verifier 已验证结论正确”。原因在于当前 confidence 来源包括节点数量、关系数量、Evidence 覆盖和固定启发式分值，它没有经过概率校准，也没有与人工真值进行独立对照。
一个最小反例足以说明风险：如果加入一条与结论语义无关、但形式上关联到节点的 Evidence，覆盖数量可能上升，confidence 也可能随之变化。数量增加不代表语义支持增强。
所以本文使用“Evidence 缺口检查”和“启发式差异”这两个词，而不是“事实核验器”或“正确率验证器”。
Persona 有两种不同含义
TraceWise 中的 Persona 容易被混在一起。
第一种是对话视角。用户可以选择 assistant、expert、project_manager 或 infrastructure。这个值进入普通 Agent 对话的 Prompt，并显示在 Context diagnostics 中，用于改变回答关注点。
第二种是实体档案。Graph 节点可以保存 role、responsibility、concerns、interaction style 和 source refs，帮助解释一个实体在项目分析中代表什么职责。
但子图编排请求本身没有 persona 字段。它接收 question、selected node、context node IDs、max subgraphs 和 depth。运行完成后，前端可以把当前 Persona 作为展示与后续提案上下文记录下来，但 Persona 没有控制 Planner 如何划分子图，也没有获得独立调度权。
真实产品截图：Persona、上下文与子图分析位于同一工作台；界面中的 Persona 是对话模式和实体档案，不是自治 Agent 实例。画面使用合成数据。
为什么仍然保留这些责任名称
把它们统称为一个大函数，会失去可观察性；把它们宣传成自治 Multi-Agent，又会超出证据。责任段是两者之间更准确的产品模型：
- Planner 让用户看到系统准备分析什么；
- Worker 让每个局部结构拥有独立结果；
- Verifier 让缺口和差异不会被最终文本掩盖；
- Synthesizer 负责表达，而不是替前面阶段重写事实；
- Runtime event 让阶段、actor、scope 和失败位置可追踪。
技术解释图：子图分析位于更大的治理流程中；生成的结论不会因此自动获得写入权。
真正的 Multi-Agent 还需要什么
如果未来要使用“Multi-Agent”这个词，至少需要补齐：
- 可独立寻址的 Worker 身份；
- 每个 Worker 的作用域和上下文预算；
- 独立任务状态、持久化与重启恢复；
- 超时、取消和失败隔离；
- 调度与资源配额；
- 版本冻结和输入快照；
- claim—Evidence 语义验证，而不仅是数量检查；
- 聚合冲突时的明确人工决策点。
这些不是命名问题，而是产品和运行时契约。
这次边界修正带来的价值
收窄说法并没有削弱项目。相反，它让工程沟通和技术审阅更扎实：
- 可以展示真实的阶段化控制流；
- 可以解释为什么选择串行执行；
- 可以指出 Verifier 的有效范围；
- 可以给出 Persona 的两种产品含义；
- 可以明确未来演进到独立 Agent 需要付出的成本。
TraceWise 将问题分解、局部分析、Evidence 缺口、冲突和最终表达组织成串行的可观察阶段。排查某个结论时，可以回到对应阶段的输入输出；输出正确率则需要在独立样本上测量。