企业官网建设流程全解析

目录

一、问题重构：稀缺的有效注意力

（一）从“能不能通信”转向“什么可以跨界”

1、通信只是物理条件，语义才是系统条件

2、边界决定了系统的真实结构

（二）为什么“更多 Context”常常带来更差的结果

1、Token 成本只是最容易看见的一层

2、未经整理的历史会制造三类假象

二、先判断是否值得拆分：Multi-Agent 是一种有代价的结构

（一）适合拆分的任务具有三个共同特征

1、并行空间足够大

2、专门权限或工具确有必要

3、中间成果可以形成稳定接口

（二）不适合拆分的任务也有清楚信号

1、步骤高度串行且共享前提持续变化

2、协调成本高于能力收益

三、六层信息面：把“Context”拆成不同责任

（一）前三层回答“Agent 当前需要知道什么”

1、全局规则面：不可被普通任务覆盖的底线

2、任务说明面：一次委派的正式边界

3、共享状态面：系统此刻共同承认的事实

（二）后三层回答“结果怎样保存、过程怎样追踪”

1、证据成果面：传引用，不反复复制正文

2、事件记录面：说明状态为什么变成现在这样

3、私有过程面：默认不跨界

四、最小充分上下文：从一句原则变成可执行选择

（一）第一道检查：拿掉它，结果会不会实质变化

1、用反事实检查必要性

2、最小不等于最短

（二）第二道检查：能不能相信、还能相信多久

1、来源决定可验证性

2、时效决定能否继续复用

（三）第三道检查：传递收益是否高于风险与成本

1、边界评分不必复杂，但必须可解释

2、把“传不传”扩展为四种动作

五、跨界数据包：让每次 Handoff 都能被机器检查

（一）一个完整数据包应包含什么

1、内容字段与控制字段必须分开

1.1 Payload 说明“结果是什么”

1.2 Metadata 说明“怎样使用结果”

2、kind 字段决定下游的默认态度

（二）数据包要支持拒绝、重试和撤回

1、拒绝必须带可修复原因

2、重试必须避免重复动作

3、撤回必须能沿依赖关系传播

六、共享状态不是一张大表：它需要一致性与所有权

（一）单一 owner 解决写冲突，读者仍可很多

1、字段所有权比 Agent 角色更精确

2、状态更新要用“读版本—判断—写新版本”

（二）状态机比自由文本更容易守住业务边界

1、关键对象应有有限状态与合法转移

2、已对外承诺的状态要特别保护

七、压缩不是写短摘要：它是有损信息处理

（一）压缩前先区分必须保真与可以舍弃

1、四类内容通常必须保留

2、结论可以压，证据链不能断

（二）压缩质量要同时看 Recall 与 Precision

1、先保住可能影响结果的信息

2、用下游任务做压缩评测

3、为摘要加“未知区”

八、安全边界：把每个 Agent 当成有限信任的服务

（一）Prompt Injection 会借跨界消息扩大影响

1、外部内容不是系统指令

2、不同信任区之间要经过清洗与重建

（二）最小权限要同时限制数据与动作

1、能读什么与能做什么是两张表

2、授权应附着在任务上，而不是永久附着在角色上

3、高风险动作需要两阶段提交

九、错误不会自动停下：必须设计故障隔离与恢复

（一）Multi-Agent 的错误有四种传播方式

1、事实传播

2、目标传播

3、状态传播

4、动作传播

（二）用断路器阻止低质量结果继续向下

1、置信度不是装饰字段

2、检查点让任务可以从中间恢复

3、局部失败不应自动变成全局失败

十、观察与评测：不要只看最终答案是否“像对的”

（一）边界质量需要一组互补指标

1、Context Precision

2、Context Recall

3、Provenance Coverage 与 Staleness Rate

4、Handoff Success 与 Conflict Rate

5、Cost per Successful Task

（二）评测要覆盖结果、过程与最终状态

1、结果评测

2、过程评测

3、最终状态评测

十一、完整案例：企业协商助手怎样按边界运行

（一）开始前：主 Agent 只建立目标与计划

1、读取全局规则与当前会话状态

2、按需唤醒专家，而不是全员常开

（二）运行中：并行探索，串行提交关键状态

1、画像 Agent 生成证据包

2、风险 Agent 生成短期标记

3、合规 Agent 审查“拟采取动作”

4、会话控制器守住对外一致性

（三）结束后：成果、事件与快照分开保存

1、成果物保存可复用内容

2、事件记录支持回放

3、共享状态只保留下一次真正需要的内容

十二、落地路径：从“共享全部对话”迁移到边界工程

（一）第一步：先画信息流，不急着增加 Agent

（二）第二步：把 Message 与 State 分开

（三）第三步：让大结果变成 Artifact

（四）第四步：在动作前加入确定性安全门

（五）第五步：用真实失败案例调优边界

（六）第六步：让系统能够退回简单路径

十三、协议位置：MCP、A2A 与内部边界各自解决什么

（一）MCP 主要连接 Agent 与外部能力

（二）A2A 主要连接不同 Agent 服务

（三）内部边界规则决定系统是否可靠

十四、进一步判断：未来竞争点会从“会协作”转向“能受控协作”

（一）Agent 数量不会成为长期优势

（二）Artifact 会比长对话更接近系统事实

（三）上下文工程最终会成为运行时系统

十五、结语：好的 Multi-Agent 不是彼此知道一切

可参考的文章与规范

干货分享，感谢您的阅读！

Multi-Agent 系统的能力，不只取决于 Agent 数量、模型强弱或工具多少，更取决于信息怎样跨越边界。全量转发对话会把无关内容、过期判断、未经核对的结论和高风险数据一起带入下游；过度隔离又会让 Agent 丢失目标、重复工作、作出前后冲突的决定。

本文在“最小充分上下文”这一思想上继续向前，提出一套可用于真实系统的边界工程：先判断任务是否值得拆分，再把信息分为全局规则、任务说明、共享状态、证据成果、事件记录和私有过程六个层面；随后用必要性、来源、时效、权限、置信度与可恢复性决定每条信息能否跨界；最后以状态机、成果物、版本控制、安全门、故障隔离和评测指标把设计变成可运行、可观察、可审计的工程系统。

成熟的 Multi-Agent 不是“让所有 Agent 看到更多”，而是让正确的信息，在正确的时点，以正确的形式和保证，进入正确的 Agent。

核心判断：Agent 的边界不是一堵墙，而是一道有规则、有记录、可回放的信息门。边界设计的目标，不是让信息自由流动，也不是把信息全部锁住，而是让每次跨界都能回答五个问题：为什么要传、谁有权传、这条信息来自哪里、还能相信多久、出错后怎样恢复。

一、问题重构：稀缺的有效注意力

（一）从“能不能通信”转向“什么可以跨界”

1、通信只是物理条件，语义才是系统条件

让两个 Agent 互相发送 Message，在工程上并不难。函数调用、消息队列、共享数据库、文件系统或 A2A 一类协议，都能提供传输能力。难点在于：一条能够送达的消息，并不等于一条应该被下游采用的事实。消息可能只是一段未完成的探索，可能来自权限不足的数据源，也可能是一个已经过期的判断。若系统把“收到”自动理解为“可信”，通信越顺畅，错误反而传播得越快。

因此，跨 Agent 传递不能只定义字段和格式，还要定义语义保证。下游至少需要知道：这条内容是事实、建议、假设还是动作请求；谁生成了它；依据是什么；置信度有多高；有效期到什么时候；能否直接触发外部动作；若发现错误，应该撤回哪一批后续结果。没有这些信息，Message 只是数据，不是可用状态。

2、边界决定了系统的真实结构

很多 Multi-Agent 原型看起来有清晰的角色：规划 Agent、搜索 Agent、分析 Agent、审查 Agent、执行 Agent。但如果它们共享同一份完整对话、同一组工具和同一套权限，那么这些角色只是 Prompt 上的名字，边界并没有真正建立。相反，即使系统只有两个 Agent，只要它们有不同的权限、独立的私有过程、明确的输入输出规则和可追踪的成果物，就已经具备了真实的软件边界。

这意味着，判断系统是否成熟，不该先数 Agent，而应检查边界：每个 Agent 能看到什么、能修改什么、必须输出什么、不能输出什么、失败时由谁接管。角色是表面结构，信息权与动作权才是深层结构。

信息跨界检查链：六项条件逐步通过后才允许直接传递；内容过多时改用压缩或成果文件，任一步失败即中断核对。

（二）为什么“更多 Context”常常带来更差的结果

1、Token 成本只是最容易看见的一层

全量共享首先会增加 Token 与延迟，但更大的问题是有效注意力被稀释。模型需要在规则、历史对话、工具结果、临时计划、失败记录和其他 Agent 的长篇输出之间判断主次。即使所有内容都是真的，也可能因为与当前子任务无关而产生干扰。Context 越长，真正决定当前动作的少数信号越容易被埋没。

“上下文窗口还能放下”并不等于“这些内容值得放进去”。窗口是容量上限，不是质量标准。一个可靠系统应把 Context 当作有限的运行资源：每次加入信息都要有明确收益，每次保留历史都要说明它对后续行为的影响。

2、未经整理的历史会制造三类假象

第一类是一致性假象。对话里出现过一个数字，后续 Agent 便可能把它当成当前值，却不知道它已经被新数据覆盖。第二类是权威假象。某个 Agent 用确定语气给出建议，下游便可能误认为它拥有决定权。第三类是完整性假象。共享了大量原始记录，看似没有丢信息，实际却没有指出哪一项是最终结论、哪一项仍待核对。

因此，Conversation History 不能直接等同于 Shared State。History 用来回放发生过什么；State 用来说明现在是什么；Artifact 用来保存可继续使用的成果。三者的用途不同，生命周期也不同。

二、先判断是否值得拆分：Multi-Agent 是一种有代价的结构

（一）适合拆分的任务具有三个共同特征

1、并行空间足够大

如果任务可以被分为多个相对独立的方向，例如同时查找不同市场、核对不同规则、分析不同数据集，多 Agent 能利用独立 Context 并行探索。各子 Agent 不必等待彼此的每一步结果，只需在阶段结束时提交结构化发现，协调收益通常大于协调成本。

2、专门权限或工具确有必要

当某类工作需要独立权限、专门工具、不同模型或高强度审查时，拆分能形成风险隔离。例如，搜索 Agent 只有只读网络权限，数据 Agent 只能访问脱敏表，执行 Agent 能写外部系统但不能自由生成动作参数，审查 Agent 能阻断动作但不能修改业务事实。此时，拆分不是为了“角色更像人”，而是为了建立最小权限与制衡关系。

3、中间成果可以形成稳定接口

若子任务能产生清晰的 Report、JSON、代码补丁、数据表、证据包或审查结论，它就适合形成独立 Agent。若子任务无法定义输入输出，只能依赖连续对话中的微妙语气和全部过程，那么强行拆分会增加“传话失真”。可形成 Artifact 的任务，通常比只能传 Message 的任务更适合多 Agent。

（二）不适合拆分的任务也有清楚信号

1、步骤高度串行且共享前提持续变化

如果每一步都依赖上一步的细节，且计划会持续被新发现改写，多 Agent 并不会带来真正并行，只会把同一 Context 复制多份，再付出汇总成本。短小代码修改、简单事实查询、单轮内容生成往往更适合 Single Agent + Tools。

2、协调成本高于能力收益

可以用一个简单判断式帮助设计：

拆分净收益 = 并行收益 + 专门能力收益 + 风险隔离收益 - 通信成本 - 状态同步成本 - 错误传播成本 - 评测与运维成本

这个式子不要求一开始就得到精确数字，但要求团队把隐性代价写出来。若只计算“多个 Agent 可以做更多”，而不计算 Token、延迟、冲突、回放和权限管理，原型容易显得惊艳，生产运行却会很快失控。

拆分判断：只有当并行、专门能力和风险隔离的合计收益高于协调代价时，Multi-Agent 才是合理选择。

三、六层信息面：把“Context”拆成不同责任

（一）前三层回答“Agent 当前需要知道什么”

1、全局规则面：不可被普通任务覆盖的底线

全局规则包括用户目标的上位约束、系统权限、业务红线、安全要求、数据使用范围和运行环境。它不应被某个子 Agent 随意改写，也不应与普通对话混在一起。规则要少而清楚，并带有版本；当规则更新时，运行中的任务要知道自己仍使用旧版，还是必须暂停并切换新版。

全局规则不等于把全部公司制度塞进 Prompt。更好的做法是保留稳定原则和检索入口：当前任务触及某类高风险动作时，再按需读取相应条款。这样既减少常驻 Context，又能让规则保持可更新、可引用。

2、任务说明面：一次委派的正式边界

任务说明是主 Agent 给子 Agent 的工作合同，应至少包含目标、范围、输入引用、允许使用的工具、禁止事项、输出格式、完成条件、时间或成本上限。只说“研究一下这个问题”通常不够，因为子 Agent 不知道应该覆盖多广、什么来源优先、何时停止、怎样让结果可合并。

好的任务说明还要写清“不做什么”。例如：“只核对事实，不给最终业务建议”“只读数据，不修改记录”“发现证据冲突时返回冲突，不自行选择一方”。负范围能减少重复工作，也能防止子 Agent 越权。

3、共享状态面：系统此刻共同承认的事实

Shared State 是经过整理的当前状态，不是消息堆。每个字段都应有 owner，关键字段还要有来源、时间、置信度、版本和有效期。对同一事实，只保留一个被系统承认的当前值，同时保留变更记录以便回放。

共享状态适合放任务进度、已确认事实、已作决定、已对外承诺、待解决问题和风险标记；不适合放搜索过程、冗长推理、完整网页、失败调用或每次模型输出。后者属于私有过程或 Artifact。

（二）后三层回答“结果怎样保存、过程怎样追踪”

1、证据成果面：传引用，不反复复制正文

Artifact 是跨 Agent 协作的主要载体。搜索 Agent 可以输出证据清单，数据 Agent 可以输出分析表，代码 Agent 可以输出补丁和测试记录，审查 Agent 可以输出带理由的判定。主 Agent 接收的应是简短摘要加稳定引用，需要细节时再读取成果物。

这种做法有三个价值：其一，大对象不必反复进入 Context；其二，成果物能独立校验和复用；其三，主 Agent 不会在转述时改变原始结果。Anthropic 在其多 Agent 调研系统经验中也强调让子 Agent 把结果写入文件，再返回轻量引用，以减少多级转述造成的信息损失。

2、事件记录面：说明状态为什么变成现在这样

Event Log 记录“谁在什么时间基于什么输入做了什么，产生了什么结果”。它服务于排查、审计和恢复，不必每轮都进入模型 Context。状态是当前快照，事件是变化过程；两者结合，系统才能在出错时回到某个检查点，并解释一个字段为什么被更新。

3、私有过程面：默认不跨界

Private Context 包括临时计划、搜索词、原始工具输出、失败尝试、中间推理和只对当前 Agent 有用的缓存。默认不传，并不代表这些信息没有价值，而是它们的价值主要在本地。需要排查时可由受权系统访问，但不应自动广播给其他 Agent。

把私有过程保留下来有助于独立探索；把它与共享状态分开，则能避免一个 Agent 的路径依赖影响其他 Agent。多个子 Agent 从不同角度独立工作，最后比较结果，往往比所有 Agent 实时观看彼此过程更容易发现遗漏。

六层信息面：全局规则与任务说明用于注入，共享状态受 owner 控制，证据成果按需读取，私有过程留在本地，事件记录服务审计。

四、最小充分上下文：从一句原则变成可执行选择

（一）第一道检查：拿掉它，结果会不会实质变化

1、用反事实检查必要性

面对候选信息，先问：“若下游看不到它，输出的事实、决定或动作会发生实质变化吗？”若不会，默认不传；若会，再检查是否能用更短形式表达。这个检查把“可能有用”改成“对当前任务有可说明的影响”。

必要性不是永久属性，而是任务相关属性。同一条客户历史，对身份核对 Agent 可能必要，对格式检查 Agent 可能完全无关；同一份代码仓库，对修改 Agent 必要，对参考来源核对 Agent 只需要提交号和测试结果。

2、最小不等于最短

若一个数字会触发真实动作，仅传数字可能太短。下游还需要单位、口径、来源、计算时间和使用限制。相反，一页自然语言说明也可能太长，因为它把结论与过程混在一起。最小充分 Context 的目标是最少的高信号信息，而不是最少字符。

（二）第二道检查：能不能相信、还能相信多久

1、来源决定可验证性

每个关键结论应指向原始数据、规则、工具结果或成果物。来源不一定都要立刻展开，但必须能被定位。对外部网页，记录链接和访问时间；对数据库，记录表、查询条件和快照时间；对模型判断，记录输入摘要、模型版本、规则版本和置信度。

没有来源的内容可以作为线索，却不应直接成为高风险动作的依据。系统可把它标记为 hypothesis 或 suggestion，要求另一个 Agent 核对后才能升级为 confirmed fact。

2、时效决定能否继续复用

有些信息长期稳定，如合同编号；有些只在一次会话内有效，如当前情绪风险；有些在外部系统更新后立即失效，如库存、价格、权限和任务状态。TTL 不应只是缓存时间，而应表示“超过这个时点，使用者必须重新确认”。

对关键字段，还要定义失效事件。例如，用户撤回授权、规则版本更新、数据源出现新快照、上游 Agent 撤回结论，都应主动让相关状态过期，而不是等待固定时间结束。

（三）第三道检查：传递收益是否高于风险与成本

1、边界评分不必复杂，但必须可解释

可以为候选信息建立一个轻量评分：

跨界价值 = 任务影响 × 来源质量 × 新鲜度 × 权限匹配 × 可恢复性 - Token 成本 - 隐私风险 - 错误传播风险

评分不是让模型凭感觉给一个总分，而是要求系统逐项留下理由。高影响但来源不明的信息，应进入核对队列；来源可靠但与任务无关的信息，不应占用 Context；高风险且不可撤回的动作，即使信息充分，也应进入人工确认。

2、把“传不传”扩展为四种动作

边界不只有允许和拒绝。更实用的结果有四种：直接传递；压缩后传递；只传 Artifact 引用并允许按需读取；阻断并请求核对。这样可避免把所有中间状态都硬塞进 Message，也能防止因为信息不完美而让整个系统停摆。

选择漏斗：候选信息经过任务影响、来源、时效、权限和风险检查后，被直接传递、压缩、改为引用或阻断。

五、跨界数据包：让每次 Handoff 都能被机器检查

（一）一个完整数据包应包含什么

1、内容字段与控制字段必须分开

1.1 Payload 说明“结果是什么”

内容字段说明“结果是什么”，控制字段说明“怎样使用这个结果”。例如，value=500只是内容；unit=CNY、source=rule_table_v3、confidence=0.90、expires_at=...、action_limit=proposal_only才决定下游能否安全使用。

1.2 Metadata 说明“怎样使用结果”

下面是一份可参考的跨界数据包。它不是固定标准，而是一套检查清单：

{ "message_id": "msg_8f2...", "task_id": "task_2026_0817", "kind": "finding", "producer": "profile_agent", "consumer": "lead_agent", "payload": { "repayment_ability": "medium", "proposal_limit": 500, "currency": "CNY" }, "evidence": [ {"artifact": "evidence/profile_0817.json", "items": ["r12", "r18"]} ], "confidence": 0.90, "created_at": "2026-08-28T10:20:00Z", "expires_at": "2026-08-28T10:50:00Z", "policy_version": "policy_v3", "sensitivity": "restricted", "allowed_use": ["draft_offer"], "forbidden_use": ["external_commitment"], "state_version": 17, "idempotency_key": "task_2026_0817:profile:v17", "on_failure": "request_recheck" }

2、kind 字段决定下游的默认态度

至少应区分fact、finding、suggestion、decision、action_request、artifact_ref、error和retraction。Fact 也许可以直接进入共享状态；Suggestion 只能进入候选区；Action Request 必须经过权限和参数核对；Retraction 要让依赖它的后续状态一起失效。

如果所有输出都只是自然语言，系统很难自动执行不同检查。给信息加类型，不是为了追求复杂 Schema，而是为了把默认安全行为写进运行层。

（二）数据包要支持拒绝、重试和撤回

1、拒绝必须带可修复原因

下游拒绝一个 Handoff 时，不应只返回“格式错误”。它应说明缺少来源、状态版本落后、权限不匹配、Artifact 不可读、TTL 已过或置信度低于动作要求。这样上游才能补充信息，而不是重复发送同一内容。

2、重试必须避免重复动作

模型调用和网络调用都可能超时。若上游不知道下游是否已经完成动作，盲目重试可能产生重复写入、重复通知或重复承诺。idempotency_key让同一请求可以安全重放：下游发现同一 key 已完成时，返回原结果，不再执行一次。

3、撤回必须能沿依赖关系传播

若上游发现事实错误，仅修改当前字段还不够。系统要知道哪些判断、报告和动作依赖了旧值。可以在成果物和状态更新中记录depends_on，形成轻量依赖图。撤回时，先把直接依赖项标为 stale，再由 owner 决定重新计算、回滚或交给人工处理。

跨界数据包：Payload 之外，还需要证据、时效、权限、版本、重复执行保护与失败处理。

六、共享状态不是一张大表：它需要一致性与所有权

（一）单一 owner 解决写冲突，读者仍可很多

1、字段所有权比 Agent 角色更精确

“画像 Agent 负责用户信息”仍然太宽。更好的设计是到字段级：identity_status由身份核对 Agent 写，risk_flags由风险 Agent 写，compliance_verdict由合规 Agent 写，committed_offers由对外会话控制器写。其他 Agent 可以提出更新建议，但不能直接覆盖。

单一 owner 并不代表单点判断。关键字段可以有多个核对者，但只有 owner 负责提交最终状态。这样既能保留制衡，也能避免多个 Agent 相互覆盖。

2、状态更新要用“读版本—判断—写新版本”

当两个 Agent 并行工作时，它们可能都基于版本 16 计算结果。第一个提交后状态变为 17，第二个再提交时若直接覆盖，就会丢失新变化。解决办法是提交时带上expected_version=16；系统发现当前已是 17，便拒绝覆盖并要求重新读取相关字段。

这种 Compare-and-Set 思路简单、确定，适合高价值状态。对只追加的事件记录，则可以并行写入，随后由 owner 汇总为新快照。

（二）状态机比自由文本更容易守住业务边界

1、关键对象应有有限状态与合法转移

例如一个外部方案可以是draft、reviewed、approved、communicated、withdrawn。只有审查通过后才能从 draft 进入 approved；只有会话控制器才能进入 communicated；withdrawn 后不能再次对外使用，除非生成新版本。

状态机把“能不能做”从 Prompt 提示变成系统约束。Prompt 可以提醒模型遵守流程，运行层则必须拒绝非法转移。两者结合，比只依赖模型自律可靠得多。

2、已对外承诺的状态要特别保护

对用户说出口的内容会产生真实预期。它与内部建议不同，不应被后台 Agent 轻易覆盖。系统需要一份独立的committed_facts或communicated_offers，记录内容、时间、渠道、审批依据和会话证据。后续生成必须先读取这份状态，发现冲突时阻断而不是自行“修正历史”。

状态更新：上半部分用 v1→v2 说明乐观并发检查，下半部分说明业务状态只能沿合法路径变化。

七、压缩不是写短摘要：它是有损信息处理

（一）压缩前先区分必须保真与可以舍弃

1、四类内容通常必须保留

第一，已确认的目标与限制；第二，已经作出的决定及其理由；第三，仍未解决的问题与依赖；第四，关键证据的稳定引用。它们决定后续 Agent 能否保持任务连续性，也决定事后能否解释为什么这样做。

工具的完整原始返回、重复描述、失败搜索词和不再相关的临时计划通常可以清理。但若失败本身改变了方案，例如某个数据源持续不可用，则应保留“不可用”这一事实和最后检查时间，而不是保留每次失败的全部日志。

2、结论可以压，证据链不能断

一个 20 步分析可以压成三行结论，但每一行关键结论都要能回到 Artifact 中的证据位置。摘要负责帮助下游快速判断；Artifact 负责保存细节；Event Log 负责说明过程。三者互补，不能用摘要替代全部记录。

（二）压缩质量要同时看 Recall 与 Precision

1、先保住可能影响结果的信息

早期调优应优先提高 Recall：宁可多保留少量边缘信息，也不要丢失决定性约束。随着评测积累，再逐步删除重复与低影响内容，提高 Precision。直接追求极短摘要，很容易把当时看似次要、后来却成为关键的线索删掉。

2、用下游任务做压缩评测

不要只问“摘要像不像原文”。更有意义的检查是：同一个下游任务，使用完整 Context 与压缩 Context 时，事实准确率、关键决定、工具选择和风险判断是否保持一致。若压缩后结果改变，应定位是哪类信息丢失，再更新压缩规则。

3、为摘要加“未知区”

高质量摘要不只写知道什么，也写不知道什么。open_questions、conflicts、missing_sources和assumptions能防止下游把沉默理解为确认。明确未知，比用流畅文字掩盖不确定更安全。

压缩与评测：原始过程逐层沉淀为成果、状态和任务包，同时用下游结果检验压缩前后关键决定是否等价。

八、安全边界：把每个 Agent 当成有限信任的服务

（一）Prompt Injection 会借跨界消息扩大影响

1、外部内容不是系统指令

搜索页面、邮件、文件和工具返回都可能含有诱导模型改变行为的文字。搜索 Agent 若把网页原文直接交给执行 Agent，恶意内容可能从只读环境进入有写权限的环境。最基本的隔离是：外部内容标为 untrusted data，只能作为证据，不得改变系统规则、工具权限或任务目标。

2、不同信任区之间要经过清洗与重建

从外部数据区进入共享状态时，不应原样转发整段文本。系统可以提取结构化事实、保留引用、删除可执行指令，并由独立核对 Agent 检查高风险字段。需要展示原文时，使用 Artifact 引用，让读者按需查看，而不是把它放入高权限 Agent 的常驻 Context。

（二）最小权限要同时限制数据与动作

1、能读什么与能做什么是两张表

某个 Agent 可能需要读取客户状态，却不需要发送消息；另一个 Agent 可以生成草案，却不应直接提交；执行 Agent 可以提交经过批准的动作，但不应自由搜索更多个人数据。数据权限和动作权限分开配置，才能避免“为了一个工具而开放全部环境”。

2、授权应附着在任务上，而不是永久附着在角色上

长期高权限角色风险很大。更稳妥的方法是为一次任务发放窄范围、短时间、可撤回的 capability：只能访问指定对象，只能执行指定动作，只在当前 task_id 下有效。任务结束后自动失效。

3、高风险动作需要两阶段提交

第一阶段只生成计划和参数，系统执行规则核对并展示影响；第二阶段在批准后才真正写入外部环境。这样即使生成 Agent 被错误内容带偏，也无法直接完成不可逆动作。对金额、权限、删除、对外承诺和公开发布等动作，Two-Phase Commit 特别有价值。

两阶段提交：第一阶段只有分析权，第二阶段依次经过规则检查、人工确认与窄范围能力授权后才能执行。

九、错误不会自动停下：必须设计故障隔离与恢复

（一）Multi-Agent 的错误有四种传播方式

1、事实传播

上游给出错误数字，下游把它作为计算基础，最终多个成果物都看似一致。因为所有结果来自同一错误源，“一致”反而会掩盖问题。关键事实需要独立来源或二次核对，不能只做多 Agent 投票；多个 Agent 读取同一错误数据，投票也不会变真。

2、目标传播

主 Agent 分解任务时遗漏一个限制，所有子任务都会在错误目标下高效工作。任务说明应回显目标、范围和完成条件，让子 Agent 在开始前检查矛盾；高价值任务可以由审查 Agent 先检查拆分计划，再启动大规模并行工作。

3、状态传播

过期或冲突状态进入 Shared State 后，会被后续 Agent 反复读取。TTL、版本检查、owner 和撤回机制是主要防线。状态错误比单条消息错误更危险，因为它具有持续影响。

4、动作传播

错误建议如果直接触发外部写入，影响可能不可逆。动作边界要比信息边界更严格：来源覆盖、规则检查、权限匹配、重复执行保护、人工确认和回滚方案应按风险逐级增加。

（二）用断路器阻止低质量结果继续向下

1、置信度不是装饰字段

系统应为不同动作定义最低证据要求，而不是只记录 confidence。低置信度可以允许进入探索阶段，却不能进入承诺阶段；来源冲突时即使模型给出高置信度，也应降级为人工核对。置信度要与来源质量、证据一致性和历史校准结合使用。

2、检查点让任务可以从中间恢复

长任务应在计划完成、数据收集完成、关键决定完成和动作提交前保存检查点。失败后从最近的稳定状态恢复，而不是重新运行全部 Agent。检查点还要记录使用的 Prompt、模型、工具和规则版本，避免恢复后在无提示的情况下改变行为。

3、局部失败不应自动变成全局失败

一个搜索方向失败，可以标记缺口并继续其他方向；一个非关键 Artifact 延迟，不应阻塞全部工作；只有当失败影响完成条件或高风险判断时，主任务才暂停。任务说明中应预先定义 critical 与 optional 输出，避免协调器在运行时临时猜测。

故障隔离：依赖标记、动作中断和检查点恢复共同把错误限制在受影响分支。

十、观察与评测：不要只看最终答案是否“像对的”

（一）边界质量需要一组互补指标

1、Context Precision

进入下游 Context 的信息中，有多少对最终结果产生可说明的影响。可以通过删除测试、注意信息引用或人工标注估计。Precision 低说明系统在发送大量噪音。

2、Context Recall

真正影响任务的关键信息中，有多少被正确传递。可把失败案例回放，检查缺失约束、证据、状态或权限。Recall 低通常表现为重复搜索、遗漏条件、错误工具选择和前后矛盾。

3、Provenance Coverage 与 Staleness Rate

前者统计关键结论中带有效来源的比例；后者统计被使用时已经过期或版本落后的状态比例。这两项比平均消息长度更能说明 Shared State 是否可靠。

4、Handoff Success 与 Conflict Rate

Handoff Success 统计数据包一次通过 Schema、权限、来源和时效检查的比例；Conflict Rate 统计并行 Agent 对同一字段提出冲突更新的频率。若冲突长期很高，问题通常不在模型，而在任务拆分或字段 owner 不清。

5、Cost per Successful Task

不能只看总 Token，也不能只看成功率。更合理的是每个成功任务的 Token、延迟和外部调用成本，并同时记录任务价值。高价值、宽泛、可并行任务可以接受更高成本；普通任务则应自动退回 Single Agent 路径。

（二）评测要覆盖结果、过程与最终状态

1、结果评测

检查事实准确、来源匹配、覆盖完整和表达质量。调研类任务可用 rubric 与人工抽查结合；有明确答案的任务可用确定规则检查。

2、过程评测

检查是否使用正确工具、是否重复工作、是否越权、是否在已有充分信息后仍继续搜索、是否把未经核对的建议升级为事实。过程没有唯一正确路线，但有明显不合理路线。

3、最终状态评测

对会修改环境的 Agent，最重要的是任务结束后系统处于什么状态：记录是否正确、动作是否只执行一次、承诺是否一致、无关对象是否未被修改、失败时是否恢复到安全点。只评模型最后说了什么，无法覆盖真实影响。

边界质量指标：相关性、完整性、一致性与恢复能力分别对应不同失败类型，不能被单一成功率替代。

十一、完整案例：企业协商助手怎样按边界运行

（一）开始前：主 Agent 只建立目标与计划

1、读取全局规则与当前会话状态

主 Agent 获取用户目标、允许讨论的方案范围、当前权限和已对外承诺。它不会读取全部历史原文，而是读取一份当前状态摘要，并保留历史 Artifact 的引用。若用户身份未确认，系统状态机阻止进入方案阶段。

2、按需唤醒专家，而不是全员常开

普通问答由主 Agent 和知识工具完成。只有出现能力评估、特殊方案、投诉风险或合规疑问时，才创建对应子任务。每个子任务都带清楚范围和输出格式，避免多个 Agent 重复查询同一内容。

（二）运行中：并行探索，串行提交关键状态

1、画像 Agent 生成证据包

它读取指定数据，输出能力档位、建议范围、来源与置信度。原始表和计算明细写入 Artifact；共享状态只接收经过 Schema 检查的字段。若数据时间过旧，结果直接标为 stale，不进入方案计算。

2、风险 Agent 生成短期标记

它只分析当前会话信号，输出风险类别、证据片段和短 TTL。它可以建议转人工，却不能修改能力数据，也不能直接结束会话。会话结束后，这些短期标记自动失效，但事件记录保留。

3、合规 Agent 审查“拟采取动作”

合规 Agent 不需要观看画像 Agent 的全部过程，只需要方案草案、关键事实、来源引用、已承诺状态和适用规则版本。它返回 pass、revise 或 block，并说明触发的规则。只有 pass 才能进入批准阶段。

4、会话控制器守住对外一致性

在生成下一句话前，它比较草案与committed_offers。若新方案与已说出口的内容冲突，系统阻断并要求主 Agent解释或转人工。对外发送后，由会话控制器原子更新承诺状态，其他 Agent 只有读取权。

（三）结束后：成果、事件与快照分开保存

1、成果物保存可复用内容

最终方案、证据包、合规判断和会话摘要分别形成 Artifact，带版本和引用关系。后续任务按需读取，不把整次对话重新塞进 Context。

2、事件记录支持回放

Event Log 保存每次状态转移、每个 Agent 的数据包摘要、工具调用结果标识和批准记录。审计人员可以从最终动作反向找到依据，也可以从某个错误事实查出受影响的后续成果。

3、共享状态只保留下一次真正需要的内容

会话结束后，短期风险标记过期；已确认身份、最新能力档位、有效方案、已对外承诺和待办事项保留。这样下一次任务从一份小而可靠的状态开始，而不是从数千行历史中重新猜测。

案例流程：专家并行生成成果，状态 owner 串行提交；对外承诺依次通过状态检查与合规检查，并写入事件记录。

十二、落地路径：从“共享全部对话”迁移到边界工程

（一）第一步：先画信息流，不急着增加 Agent

列出当前任务中的输入、状态、成果、动作和外部系统，标记每条信息从哪里来、到哪里去、谁能修改、出错后影响什么。这个图通常会暴露重复读取、全量广播、无 owner 字段和高权限 Agent。

（二）第二步：把 Message 与 State 分开

保留消息用于协作，把被系统承认的事实放入独立 Shared State。先选择少数高价值字段，如任务状态、关键决定、已对外承诺和风险标记，为它们加入 owner、source、version 与 TTL。不要一开始就设计一张覆盖全部业务的大表。

（三）第三步：让大结果变成 Artifact

把网页正文、分析表、代码、报告和长工具输出从消息中移出，改为成果物加摘要引用。为 Artifact 加稳定 ID、内容类型、生成者、时间、版本、摘要和依赖关系。主 Agent 只在需要时读取具体部分。

（四）第四步：在动作前加入确定性安全门

对写数据库、发消息、改权限、删除内容、提交金额和公开发布等动作，建立运行层检查。模型给出意图与参数，系统核对状态、权限、规则、重复执行 key 与批准记录。安全门拒绝时返回可修复原因。

（五）第五步：用真实失败案例调优边界

从二十个左右代表性任务开始，记录哪些信息被多传、哪些被漏传、哪里发生冲突、哪个字段过期、哪次重试产生重复动作。先修正明显的大问题，再逐步建立自动评测。边界规则来自失败证据，不应只来自架构想象。

（六）第六步：让系统能够退回简单路径

协调器应根据任务复杂度选择 Single Agent、Single Agent + Tools 或 Multi-Agent。简单任务走短路径；高价值且可并行的任务才启用完整结构。按需 Multi-Agent 不只是节省成本，也能减少不必要的故障模式。

十三、协议位置：MCP、A2A 与内部边界各自解决什么

（一）MCP 主要连接 Agent 与外部能力

MCP 为 LLM 应用连接资源、Prompt 与工具提供标准方式，并强调用户同意、数据保护和工具安全。它解决“怎样接入 Context 与能力”，但不会替应用决定哪条业务状态应该跨越 Agent 边界。应用仍要设计 owner、TTL、来源和动作门。

（二）A2A 主要连接不同 Agent 服务

A2A 定义 Agent Card、Task、Message、Artifact、状态更新、流式事件与安全方式，适合跨框架或跨组织的 Agent 协作。它能标准化“怎样交换任务与成果”，但业务语义仍需双方共同约定。例如 Artifact 有 ID 和 parts，不等于其中每个结论都自动可信。

（三）内部边界规则决定系统是否可靠

OpenAI Agents SDK、AutoGen 等运行框架提供 Handoff、团队、状态、终止条件、Guardrail 和 Trace 等能力。框架能降低实现成本，却不能替代边界判断。团队必须明确任务说明、共享状态 Schema、权限、错误处理和评测标准。

十四、进一步判断：未来竞争点会从“会协作”转向“能受控协作”

（一）Agent 数量不会成为长期优势

更多 Agent 很容易复制，可靠边界却来自长期工程积累：清楚的数据语义、稳定的状态模型、经过失败案例验证的规则、可回放的事件、校准后的风险门和真实业务评测。系统能力越强，边界的重要性越高，因为错误动作的影响也更大。

（二）Artifact 会比长对话更接近系统事实

未来的 Agent 协作会越来越像软件服务：对外暴露能力、任务、成果和状态，而把内部实现保持私有。Message 负责协调，Artifact 负责交付，State 负责共同事实，Event 负责解释变化。对话仍然重要，但不再承担全部存储和控制责任。

（三）上下文工程最终会成为运行时系统

今天很多 Context Engineering 仍依赖 Prompt 和人工经验；更成熟的形态会把选择、压缩、来源核对、权限、TTL、版本、撤回和评测写入运行层。模型负责理解开放问题，确定性系统负责守住不能出错的边界。

十五、结语：好的 Multi-Agent 不是彼此知道一切

Multi-Agent 的真正难题，不是让多个模型开始说话，而是建立一套让信息可以被正确使用的秩序。信息太少，协作断裂；信息太多，注意力、成本与风险一起上升。解决这个矛盾的关键，是把 Context 从一段不断增长的对话，改造成分层、带来源、带时效、带权限、带版本的系统状态与成果网络。

一套成熟设计应坚持以下原则：

1. 先证明任务值得拆分，再增加 Agent；

2. 全局规则、任务说明、共享状态、成果、事件和私有过程分开管理；

3. 每条跨界信息都经过必要性、来源、时效、权限和风险检查；

4. 关键状态有单一 owner、版本控制和合法状态转移；

5. 长结果写入 Artifact，Message 只带摘要与引用；

6. 关键动作经过确定性安全门、重复执行保护和必要的人工批准；

7. 用 Context Precision、Recall、来源覆盖、过期率、冲突率、成本与恢复能力共同评测；

8. 系统始终保留退回 Single Agent 简单路径的能力。

最后可以把全文压成一句话：

让正确的信息，在正确的时点，以正确的形式和保证，进入正确的 Agent；让其他信息留在它应该停留的地方。

可参考的文章与规范

1. 原始参考文章：Multi-Agent 的真问题：什么信息该跨越 Agent 的边界？

2. ReAct: Synergizing Reasoning and Acting in Language Models

3. Anthropic: Effective context engineering for AI agents

4. Anthropic: How we built our multi-agent research system

5. A2A Protocol Specification

6. Model Context Protocol Specification

7. OpenAI Agents SDK

8. Microsoft AutoGen: Teams

9. Beyond Self-Talk: A Communication-Centric Survey of LLM-Based Multi-Agent Systems

10. NIST AI 600-1: Generative AI Profile

11. OWASP: LLM Prompt Injection Prevention Cheat Sheet