以任务、状态与验证为核心的多Agent系统架构

当前关于Agent系统的讨论中，一种常见的设计思路是将人类组织的分工模式直接映射到多Agent系统中。系统被划分为产品经理、研究员、工程师、审查员、测试员和协调者等不同角色，然后期望这些角色能够像一个小型研发团队一样协同工作。这种设计直观易懂，便于原型展示，因此在早期的概念验证系统中被广泛采用。
这种设计的问题在系统扩展时会逐渐显现。人类组织经验提供了一个直观的参照框架，但Agent系统的效率瓶颈与人类组织存在根本差异。人类分工建立在能力异质、训练周期长、记忆与注意力有限、沟通成本高这些约束之上。大模型驱动的Agent同样面临约束，只是约束的结构不同。它们共享模型先验，可以被快速创建和回收，角色切换主要依赖上下文、工具和权限配置，很少依赖长期训练形成的稳定职业能力。
因此，讨论理想的Agent架构时，更稳妥的起点是识别系统本身的约束条件。岗位名称可以保留为界面层的标签，方便用户理解，但架构设计的核心原则应当围绕任务图、共享状态、调度策略、验证机制和写入纪律展开。下文将沿着这条思路展开，并给出一组形式化定义来精确描述系统的核心组件。

人类分工的局限

人类组织中岗位的稳定性，来自对特定能力的长期投资和能力边界的难以替代性。一个资深外科医生很难在短时间内转入芯片设计领域，一个后端工程师也很难在一周内承担成熟法务的职责。岗位分化降低了重复训练成本，也降低了组织协调中的不确定性。
Agent系统的情况有本质区别。若多个Agent共享同一模型底座，它们在知识先验上的差异通常没有人类职业分化那样陡峭。系统中更常见的差别，来自当前持有的上下文、可调用的工具、可写入的状态范围，以及局部目标函数。一个实例持有代码仓库、测试框架和失败日志，另一个实例仅能读取需求文档，它们会表现出明显不同的行为倾向。差异的来源已经落在上下文和权限分配上。
这也是某些前端Agent、后端Agent或PM Agent看起来有效的原因。有效因素通常藏在边界设置中：读哪些文件，能写哪些状态，谁来验收，谁来提交。岗位名本身提供的是沟通便利，系统性能的决定因素仍然是约束设计。

核心概念形式化定义

为了让讨论脱离岗位隐喻，我们先给出Agent系统的一组最小化定义。这个定义只提取对架构设计至关重要的核心对象。
定义 1：Agent 实例
将一个 Agent 实例记为

a = (m, c, \tau, o)

其中 $m$ 表示底层模型， $c$ 表示当前上下文， $\tau$ 表示工具与权限集合， $o$ 表示当前目标或局部优化目标。这个定义强调，同一模型上的两个实例，只有在上下文、权限或目标不同的时候，才会稳定地产生行为差异。
定义 2：任务图
将一个任务节点记为

n_i = (x_i, y_i, \alpha_i, R_i, W_i)

其中 $x_i$ 是输入上下文， $y_i$ 是期望产物， $\alpha_i$ 是验收条件， $R_i$ 和 $W_i$ 分别表示该节点需要读取和允许写入的状态范围。所有节点与依赖关系组成任务图 $G = (N, E)$ 。
这个定义带来一个直接结论：任务拆分不只是把目标切成更小的句子，拆分动作还要同步定义输入、输出、验收与读写边界。缺少这些约束时，节点数量增加通常只会放大交接成本。
定义 3：Agent 系统
将一个 Agent 系统记为

\mathcal{S} = (\mathcal{A}, G, \Sigma, \Pi, V)

其中 $\mathcal{A}$ 是 Agent 实例集合， $G$ 是任务图， $\Sigma$ 是外部共享状态， $\Pi$ 是调度策略， $V$ 是验证与提交机制。
这个定义有两个重要推论。任务图和共享状态属于系统层，不属于某个单独Agent。验证机制也属于系统层，它需要独立维护，不能压缩为生成链路中的一次自检。
定义 4：责任面
责任面可以记为

r = (R, W, g, q)

其中 $R$ 表示可读范围， $W$ 表示可写范围， $g$ 表示局部目标， $q$ 表示退出或验收条件。责任面描述的是稳定职责。职业身份只是外层标签。工程上可执行的分工，大多围绕责任面展开。
用这组定义回看多Agent设计，很多问题会变得清晰。系统设计的关键工作，是为任务节点选择合适的责任面，为责任面分配合适的上下文、权限与验证路径，然后再决定由几个Agent实例去承担这些责任。

系统核心稀缺资源

从这组定义出发，系统中最稀缺的资源可以归纳为五类。架构设计的核心就是对这些资源进行合理分配和管理。

1. 上下文

无论模型上下文窗口多大，都存在注意力稀释效应，且窗口本身有物理上限。一个已经进入问题内部的Agent，会持续积累局部线索、失败尝试、暂时搁置的假设，以及接口层面的暗知识。这些内容很难完整打包给下一个实例。任务一旦频繁转手，系统就会付出额外成本。
一个粗略的交接成本可以写成

C_{\mathrm{handoff}} = C_{\mathrm{ctx}} + C_{\mathrm{align}} + C_{\mathrm{merge}}

其中 $C_{\mathrm{ctx}}$ 表示上下文整理与压缩成本， $C_{\mathrm{align}}$ 表示目标重新对齐成本， $C_{\mathrm{merge}}$ 表示结果合并成本。很多过度拆分的系统，实际问题正是低估了这三项成本。

2. 状态一致性

人类团队可以在相当程度上依赖默契和口头补充，Agent系统做不到这一点。只要多个实例同时处理同一任务，没有外部化的共享状态，它们就会分别围绕不同快照工作。讨论看起来很充分，项目现实却在悄悄分叉。
共享状态至少要覆盖四类对象：任务状态、稳定工件、决策记录和验证记录。若状态只存在于局部会话里，系统会不断遗失前提，重复走过已经失败的分支。

3. 验证带宽

生成内容的成本已经下降得很快，验证成本仍然高。工程上更紧张的资源，通常是单位时间内能够完成多少有效验证；token产出能力反而相对宽松。若单位时间生成量记为 $g$ ，单位时间验证量记为 $v$ ，当 $g > v$ 持续出现时，系统就会累积未经验证的状态债务。债务积累到一定程度，后续每一次提交都会变得更慢，也更不稳定。
因此，架构设计要优化的对象，通常是有效通过率和错误拦截率。原始产出速度往往排在后面。

4. 关键路径时间

复杂任务的总耗时更接近任务图关键路径的长度，难以用Agent数量做简单估计。形式上可以写成总耗时主要受 $L_{\mathrm{cp}}(G)$ 约束，其中 $L_{\mathrm{cp}}(G)$ 表示任务图 $G$ 的关键路径长度。一个实例在非关键路径上做局部精修，价值可能低于另一个实例尽快解锁核心依赖。
这条约束很容易被忽视。很多系统看上去忙碌，日志也很热闹，真正推进任务的部分却很少。调度层如果不能持续识别关键路径，多Agent只会提高并发表象。

5. 写入权与行动权

Agent的生成速度远高于人的审核速度。写入权一旦模糊，错误会极快进入共享状态，然后被后续节点当作既成事实继续消费。行动权也类似。谁能调用外部API，谁能修改生产环境，谁能执行高风险工具，谁只能生成草案，这些边界都需要在系统层明确。
因此，理想的分工问题可以改写为另一组更具体的工程问题：谁拿着哪段上下文，谁对哪类状态负责，谁可以写入，谁负责验证，谁盯住关键路径。

多 Agent 拆分工程判据

多Agent架构的收益来自并行、独立审查和上下文聚焦，同时会引入交接、合并和额外验证的成本。只有当收益超过成本时，拆分才有意义。
一个可操作的工程判据可以写成

\Delta_{\mathrm{split}} = B_{\mathrm{parallel}} + B_{\mathrm{check}} + B_{\mathrm{focus}} - C_{\mathrm{handoff}} - C_{\mathrm{merge}} - C_{\mathrm{verify}}

这里的 $B_{\mathrm{parallel}}$ 表示并行收益， $B_{\mathrm{check}}$ 表示独立审查带来的收益， $B_{\mathrm{focus}}$ 表示局部上下文压缩后获得的专注收益。对应的三项成本分别来自交接、合并和额外验证。这个表达式不构成严格的数学定理，而是一个工程上的参考框架，用于评估拆分的合理性。
在这个判据下，单Agent闭环通常应当成为默认策略。高耦合、信息密集、边界模糊的任务，往往更适合由一个持有完整上下文和工具集的强Agent先跑通闭环。只有在下列情形出现时，多Agent才更有价值。
任务图中存在相互独立的子问题，拆分后能够形成真实的并行收益。
系统需要独立验证视角，例如一个实例负责生成，另一个实例专门寻找反例、边界条件和失败模式。
局部上下文已经膨胀到单个实例难以稳定承载，拆出一个较小问题域可以降低理解负担。
这里的拆分依据来自任务结构和验证需求，岗位想象很难直接提供这样的判据。

四层架构设计

在工程实现上，成熟的Agent系统可以被理解为一个任务操作系统。它至少包含四层稳定结构。

1. 任务图层

任务图层负责把高层目标编译为可执行节点。每个节点都应写明输入、产物、验收条件、依赖关系、读写边界和失败后的影响范围。待办清单只能告诉系统要做什么，任务图还需要告诉系统先做什么、做到什么程度算完成、哪个节点失败会污染全局。
任务图一旦缺失，多个Agent很容易在语义相近的位置重复劳动，或者围绕不同理解同时推进。系统表面上并行，内部却缺少可验证的依赖结构。

2. 共享状态层

共享状态层负责保存可复用的系统记忆。这里的记忆指向可查询、可版本化、可审计的对象集合，不应退化为松散聊天记录。它通常包含四类内容：任务状态、稳定工件、决策记录和验证记录。
任务状态回答节点是否开始、是否阻塞、是否完成。稳定工件包括代码、文档、接口定义、配置和中间草稿。决策记录保存拆分理由、路线选择和放弃原因。验证记录保存测试结果、审查意见、失败样例和回滚信息。Agent实例可以随时回收，这些对象需要持续存在。

3. 调度层

调度层负责根据任务图和共享状态做分配决策。它关心的对象是任务流，带有人格色彩的角色划分只提供辅助表述。一个有效的调度策略 $\Pi$ 至少要同时考虑五件事：关键路径优先级、上下文连续性、权限兼容性、验证负担和成本预算。
这里很容易出现一个误解，以为动态调度等于随时改派。实际工程里，频繁改派会持续触发上下文装载和目标重对齐，最终把时间消耗在切换上。调度层需要灵活，但它更需要克制。

4. 验证与提交层

验证与提交层负责把生成内容变成系统认可的结果。这里至少应包含自动检查、测试执行、对抗式审查、提交闸门和失败回滚。验证动作需要与生成动作保持一定独立性。提交动作则应限制在少数责任面内，避免共享状态被并发污染。
一旦这一层缺席，系统会把说得通等同于可接受，把局部自洽当作整体正确。复杂任务里，这种偏差会越滚越大。

专业化形成机制

Agent可以表现出很强的专业化能力，但这种专业化的形成机制与人类不同。人格化提示词能够改变语气和偏好，却很难单独提供稳定的专业边界。系统真正依赖的，是运行时分配给实例的上下文、工具和权限。
一个长期接触代码仓库、测试框架和失败日志的实例，会逐渐表现出工程执行器的工作方式。一个只读风险清单、接口约束和历史事故的实例，行为会更接近审查者。一个持续维护任务图与优先级的实例，则更容易形成调度者的工作模式。这里的专业化是一种结构诱导结果。
这条判断对系统设计很重要。若把专业化完全压在提示词人格上，输出风格可能很鲜明，职责边界却很松散。若把专业化压在上下文、权限和验收机制上，系统行为通常更稳定，也更容易做故障分析。

系统运行节奏

关于动态调度的讨论中，一种常见的观点认为系统应当持续重新计算任务分配，随时改派任务。这个想法在纸面上很有吸引力，落到工程实现里却经常带来另一种损耗：实例不断切换，任务很少真正做穿。
更合理的运行节奏是阶段边界驱动的重规划。一个实例一旦接住上下文清晰、读写边界明确的任务，就应在一个小周期内持续推进，直到遇到明确的边界事件。边界事件可以记为

\mathcal{B} = \left\{ \text{阶段完成},\, \text{阻塞出现},\, \text{关键验证返回},\, \text{优先级变化} \right\}

只有在 $\mathcal{B}$ 中的事件出现后，调度层才重新计算任务分配。这样的节奏有两个好处。上下文连续性能够被保留下来，系统也能避免把灵活性消耗成无休止的抖动。

常见失效模式

基于前面的定义和分析，我们可以识别出多Agent系统中几种常见的失效模式。

系统拥有完整的岗位命名，却没有定义清楚读写范围、验收条件和提交纪律，导致角色很多，责任面空白。
多个实例频繁讨论，同一任务的共享状态却没有统一版本，导致会话很多，事实源分裂。
每个子任务都很小，交接和合并成本却持续累积，并行收益很难兑现，导致任务切得过碎。
系统缺少独立审查，生成与批准落在同一链路里，最终容易把自我一致性误当成正确性。
多个实例都能修改关键状态，版本冲突和事实污染会快速增加，导致写入权限扩散。
这些问题都指向：多Agent架构的难点落在状态、责任、验证和提交纪律的维护上。

架构评估核心维度

综合以上分析，我们可以勾勒出一个更合理的Agent系统架构图景。
理想的Agent架构围绕任务图、共享状态、调度策略和独立验证展开。它把Agent视为可调度、可替换、可回收的执行节点，把稳定性放在系统外部对象上。系统默认用单Agent跑通强耦合闭环，只在并行收益、独立验证收益或上下文压缩收益足够明确时再拆分。分工单位采用责任面，责任面由读写边界、局部目标和验收条件共同定义。专业化则来自上下文、工具和权限的持续绑定。
这样设计之后，架构评估就会落到几个更有操作性的检查项上。系统能否持续识别关键路径。上下文切换是否受到控制。写入权与验证权是否分离。关键状态是否已经外部化并保持可审计。若这些条件成立，多Agent协作才会稳定地产生收益。