专题演讲嘉宾：高梓耕

长程多智能体协作的难点不只是生成计划，而是跨角色、跨系统地确认责任、进度、验收和故障恢复。我们将运行基础分为三层：Room 负责通信、定向唤醒和持久队列；Agent Runtime 负责每个成员的独立执行；WorkGraph 以"计划版本—工作项—分派—执行—提交—评审—验收"构成责任链，验收通过才解锁下游，另有一张运行图如实记录实际执行过程。工程上采用不可变计划版本、幂等请求、持久发件箱与回执、未知结果先对账，并区分重试、返工、续跑三类循环，支持动态改计划、人工确认与可追溯返工。

演讲提纲

1. 问题背景：为什么单智能体和松散多智能体仍然不够
   •  企业任务的复杂性：任务往往跨越部门、系统和执行周期，包含拆分、依赖、审批、交付、复核和返工；一次对话或一次模型调用无法保存完整过程。
   • 单智能体的边界：一个 Agent 可以理解目标、制定局部计划并调用工具，但当任务需要多人协作、并行推进或长期等待时，责任、状态和上下文容易失真。
   • 现有多智能体的缺口：Subagent 能够被临时调用完成局部工作，却不天然提供持久的负责人、交付物、验收条件、权限边界和失败后的继续方式。
   • 企业级要求：系统必须回答“谁负责、做到什么算完成、当前是否可以继续、结果由谁确认、失败后如何恢复”，并且能够留下可复查的证据。
   • 核心观点：企业需要的不只是让更多 Agent 参与，而是把 Agent 的动态决策放入一套持久、可校验、可恢复的任务网络；这也是 Graph Engineering 要解决的问题。
2. 我们是怎么思考的：从已有协作能力推导 WorkGraph
   • 先区分已有能力各自解决什么问题
     • Subagent：适合把当前任务交给另一个 Agent 协助处理，通常围绕父任务产生一次局部执行和结果；它解决“如何获得帮助”，不自动解决“业务责任如何持续存在”。
     • Room：负责成员之间的消息可见范围、唤醒、回复路由、队列和投递回执；`@` 表示沟通或邀请参与，不等于正式派工，Room 本身也不判定业务完成。
     • Goal：保存跨多次执行的目标、完成条件和目标生命周期；Goal 说明“为什么做、做到什么算完成”，不替代 Work Item、Assignment、Submission 或 Acceptance。
     • Workflow 与动态工作流：固定流程便于复用和审计；以 Claude Code 的 dynamic workflow 为例，模型可以根据上下文决定下一步，但如果只有流程节点或对话记录，仍不足以表达每次真实执行的身份、授权、验收和恢复历史。
   •  明确企业场景仍缺少的中间层
     • 企业任务需要在“固定流程的可控性”和“Agent 决策的适应性”之间取得平衡：主路径、依赖和审批边界应当可校验，具体分支和下一步可以根据实际结果调整。
     • 执行过程需要持久化责任，而不是把关键状态只放在上下文或聊天记录中；需要区分计划、当前负责人、一次尝试、交付声明和评审结论。
     • 失败不能简单等同于重试：外部系统可能已经执行但结果未知，评审驳回可能需要回到上游，长期目标也可能在当前执行结束后继续推进。
   •  WorkGraph 的提出与范围
     • WorkGraph 是什么：Nexus 中用于保存复杂工作的持久责任图。它把目标拆成带交付物和验收条件的工作项，记录依赖、负责人、尝试、交付、评审和失败后的继续方式。
     • WorkGraph 能做什么：让多 Agent 协作从“互相发消息”进入“有责任、有条件、有证据地推进任务”，同时保留动态路由和人工介入的空间。
     • 两层图的关系：责任图记录应该完成什么、谁负责、什么条件下可以继续；运行图记录 Agent、Subagent、工具和评审实际发生了什么。运行图用于观察，不能单独授予权限或触发重试。
3. WorkGraph 的设计与实现：把执行过程变成可管理的责任链
   • 核心对象与状态关系
     • 责任链：Goal → Execution → Plan → Work Item → Assignment → Attempt → Submission → Review / Acceptance。每一层有独立身份和状态，避免用一条消息或一次工具成功代替完整业务过程 
     • 计划进入执行：Agent 先提交结构化 Plan proposal；服务端解析并校验依赖、交付物和目标绑定，确认后再 materialize 成正式 Execution、Plan 和 Work Item 
     • 计划版本：Plan revision 不可变；重新规划产生新版本，旧版本保留为历史，避免旧 Agent 继续使用已经失效的计划和授权 
     • 工作项契约：每个 Work Item 明确目标、输入引用、交付物、验收标准、依赖和是否为终点节点，使“做完”具备可检查的含义 
     • 责任与尝试分离：Assignment 表示当前由谁负责，Attempt 表示一次真实执行；接管、失败或返工都会创建新的责任或尝试身份，不覆盖历史 
     • 交付与验收分离：Submission 是执行者提交结果的声明，Acceptance 是评审者作出的结论；只有 accepted 才能解除硬依赖并推动下游。
   •  Room 与 WorkGraph 的运行协同
     • 协调者通过正式派工将 Work Item、Assignment 和 Attempt 与 Room 成员绑定；成员获得精确的 WorkBinding 后才具备对应提交权限 
     • Room 处理消息投递和协作上下文，WorkGraph 处理责任转移、依赖解锁、提交评审和完成判定，两者通过持久状态和回执连接。
     • 前端图和运行记录是只读投影，不能因为点击节点、看到某条消息或观察到工具成功就直接修改责任关系 
   • Loop Engineering 的关键实现
     • Retry：针对同一工作目标创建有明确 previous identity 的新尝试，保留原执行结果。
     • Loop-back：评审驳回或要求修改时，回到上游工作项，保留原 Submission、Review 和 Gate，并创建新的 Attempt 
     • Continuation：当前 Execution 完成后，Goal 仍可通过新的执行继续推进，不把下一阶段伪装成旧执行的补丁
     • 结果未知：外部请求超时或进程中断时，依据原 request identity、receipt 和 outbox 对账；在确认未产生副作用前，不自动重放写操作
4. 工程实践与落地边界：哪些问题必须由系统承担
   • 状态和证据：关键责任进入持久化状态，执行结果通过 Submission 和 Acceptance 形成证据；聊天记录和运行日志只能作为辅助信息 
   • 权限和人工介入：模型不能自行提供 owner、Agent、Assignment 或 Attempt 身份；高风险写入、业务审批和异常接管需要明确的权限和人工边界 
   • 失败恢复：把“失败”“等待输入”“结果未知”“被驳回”和“目标继续”区分开，分别设计对账、返工、接管和继续执行路径 
   • 效果度量：建议同时观察任务成功率、人工介入率、处理周期、返工次数、未知结果对账率和最终业务结果，避免只用模型调用次数或单轮成功率评价系统。
   • 当前仍需验证的部分：跨系统副作用的对账、复杂任务的长期成本、动态计划的审计粒度、人工审批效率和不同行业的验收标准，都需要结合具体业务持续验证 
5. 总结：从“会协作的 Agent”走向“可持续推进的任务系统”
   • 第一，通信不等于派工：Room 解决协作传递，WorkGraph 记录责任和条件 
   • 第二，执行不等于完成：Attempt 成功只是过程事实，Submission 还需要经过 Review 和 Acceptance 
   • 第三，超时不等于失败：先依据稳定身份对账，再决定重试、返工或接管 
   • 第四，动态不等于失控：让 Agent 决定局部路径，让平台守住身份、依赖、权限、验收和恢复边界 
   • 最终收束：Loop Engineering 关注任务如何在反馈和异常中继续推进，Graph Engineering 关注责任如何被表达、验证和追溯；两者结合，才有可能支撑企业级多 Agent 任务

听众受益

• 分享我们对企业级多 Agent 分工的理解：结合 Room 与 WorkGraph 的设计过程，说明通信协作、任务责任和运行观察之间如何划分边界，为类似系统的架构设计提供一种参考
• 讨论长任务与异常处理中的实际问题：结合 Assignment、Attempt、Submission、Acceptance 等模型，分享我们在处理重试、返工、人工接管和外部系统结果未知时遇到的问题与解决思路