目录一、问题重构稀缺的有效注意力一从“能不能通信”转向“什么可以跨界”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 与 Precision1、先保住可能影响结果的信息2、用下游任务做压缩评测3、为摘要加“未知区”八、安全边界把每个 Agent 当成有限信任的服务一Prompt Injection 会借跨界消息扩大影响1、外部内容不是系统指令2、不同信任区之间要经过清洗与重建二最小权限要同时限制数据与动作1、能读什么与能做什么是两张表2、授权应附着在任务上而不是永久附着在角色上3、高风险动作需要两阶段提交九、错误不会自动停下必须设计故障隔离与恢复一Multi-Agent 的错误有四种传播方式1、事实传播2、目标传播3、状态传播4、动作传播二用断路器阻止低质量结果继续向下1、置信度不是装饰字段2、检查点让任务可以从中间恢复3、局部失败不应自动变成全局失败十、观察与评测不要只看最终答案是否“像对的”一边界质量需要一组互补指标1、Context Precision2、Context Recall3、Provenance Coverage 与 Staleness Rate4、Handoff Success 与 Conflict Rate5、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 说明“结果是什么”内容字段说明“结果是什么”控制字段说明“怎样使用这个结果”。例如value500只是内容unitCNY、sourcerule_table_v3、confidence0.90、expires_at...、action_limitproposal_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_version16系统发现当前已是 17便拒绝覆盖并要求重新读取相关字段。这种 Compare-and-Set 思路简单、确定适合高价值状态。对只追加的事件记录则可以并行写入随后由 owner 汇总为新快照。二状态机比自由文本更容易守住业务边界1、关键对象应有有限状态与合法转移例如一个外部方案可以是draft、reviewed、approved、communicated、withdrawn。只有审查通过后才能从 draft 进入 approved只有会话控制器才能进入 communicatedwithdrawn 后不能再次对外使用除非生成新版本。状态机把“能不能做”从 Prompt 提示变成系统约束。Prompt 可以提醒模型遵守流程运行层则必须拒绝非法转移。两者结合比只依赖模型自律可靠得多。2、已对外承诺的状态要特别保护对用户说出口的内容会产生真实预期。它与内部建议不同不应被后台 Agent 轻易覆盖。系统需要一份独立的committed_facts或communicated_offers记录内容、时间、渠道、审批依据和会话证据。后续生成必须先读取这份状态发现冲突时阻断而不是自行“修正历史”。状态更新上半部分用 v1→v2 说明乐观并发检查下半部分说明业务状态只能沿合法路径变化。七、压缩不是写短摘要它是有损信息处理一压缩前先区分必须保真与可以舍弃1、四类内容通常必须保留第一已确认的目标与限制第二已经作出的决定及其理由第三仍未解决的问题与依赖第四关键证据的稳定引用。它们决定后续 Agent 能否保持任务连续性也决定事后能否解释为什么这样做。工具的完整原始返回、重复描述、失败搜索词和不再相关的临时计划通常可以清理。但若失败本身改变了方案例如某个数据源持续不可用则应保留“不可用”这一事实和最后检查时间而不是保留每次失败的全部日志。2、结论可以压证据链不能断一个 20 步分析可以压成三行结论但每一行关键结论都要能回到 Artifact 中的证据位置。摘要负责帮助下游快速判断Artifact 负责保存细节Event Log 负责说明过程。三者互补不能用摘要替代全部记录。二压缩质量要同时看 Recall 与 Precision1、先保住可能影响结果的信息早期调优应优先提高 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 RateHandoff 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 与工具怎样取得数据、调用能力Resource、Tool、Prompt哪些数据可读、结果怎样进入状态Agent 与 Agent怎样发现、委派、更新与交付Agent Card、Task、Message、Artifact业务语义、来源要求、TTL、owner应用内部边界什么信息在何种条件下跨界State Schema、Handoff 数据包、安全门这是系统本身的核心设计十四、进一步判断未来竞争点会从“会协作”转向“能受控协作”一Agent 数量不会成为长期优势更多 Agent 很容易复制可靠边界却来自长期工程积累清楚的数据语义、稳定的状态模型、经过失败案例验证的规则、可回放的事件、校准后的风险门和真实业务评测。系统能力越强边界的重要性越高因为错误动作的影响也更大。二Artifact 会比长对话更接近系统事实未来的 Agent 协作会越来越像软件服务对外暴露能力、任务、成果和状态而把内部实现保持私有。Message 负责协调Artifact 负责交付State 负责共同事实Event 负责解释变化。对话仍然重要但不再承担全部存储和控制责任。三上下文工程最终会成为运行时系统今天很多 Context Engineering 仍依赖 Prompt 和人工经验更成熟的形态会把选择、压缩、来源核对、权限、TTL、版本、撤回和评测写入运行层。模型负责理解开放问题确定性系统负责守住不能出错的边界。十五、结语好的 Multi-Agent 不是彼此知道一切Multi-Agent 的真正难题不是让多个模型开始说话而是建立一套让信息可以被正确使用的秩序。信息太少协作断裂信息太多注意力、成本与风险一起上升。解决这个矛盾的关键是把 Context 从一段不断增长的对话改造成分层、带来源、带时效、带权限、带版本的系统状态与成果网络。一套成熟设计应坚持以下原则先证明任务值得拆分再增加 Agent全局规则、任务说明、共享状态、成果、事件和私有过程分开管理每条跨界信息都经过必要性、来源、时效、权限和风险检查关键状态有单一 owner、版本控制和合法状态转移长结果写入 ArtifactMessage 只带摘要与引用关键动作经过确定性安全门、重复执行保护和必要的人工批准用 Context Precision、Recall、来源覆盖、过期率、冲突率、成本与恢复能力共同评测系统始终保留退回 Single Agent 简单路径的能力。最后可以把全文压成一句话让正确的信息在正确的时点以正确的形式和保证进入正确的 Agent让其他信息留在它应该停留的地方。可参考的文章与规范原始参考文章Multi-Agent 的真问题什么信息该跨越 Agent 的边界ReAct: Synergizing Reasoning and Acting in Language ModelsAnthropic: Effective context engineering for AI agentsAnthropic: How we built our multi-agent research systemA2A Protocol SpecificationModel Context Protocol SpecificationOpenAI Agents SDKMicrosoft AutoGen: TeamsBeyond Self-Talk: A Communication-Centric Survey of LLM-Based Multi-Agent SystemsNIST AI 600-1: Generative AI ProfileOWASP: LLM Prompt Injection Prevention Cheat Sheet 
长河君 · 2026/10/9 5:19:06 · 阅读 1.2k 让信息有边界：Multi-Agent 系统的上下文接口、状态规则与可靠工程
目录一、问题重构稀缺的有效注意力一从“能不能通信”转向“什么可以跨界”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 与 Precision1、先保住可能影响结果的信息2、用下游任务做压缩评测3、为摘要加“未知区”八、安全边界把每个 Agent 当成有限信任的服务一Prompt Injection 会借跨界消息扩大影响1、外部内容不是系统指令2、不同信任区之间要经过清洗与重建二最小权限要同时限制数据与动作1、能读什么与能做什么是两张表2、授权应附着在任务上而不是永久附着在角色上3、高风险动作需要两阶段提交九、错误不会自动停下必须设计故障隔离与恢复一Multi-Agent 的错误有四种传播方式1、事实传播2、目标传播3、状态传播4、动作传播二用断路器阻止低质量结果继续向下1、置信度不是装饰字段2、检查点让任务可以从中间恢复3、局部失败不应自动变成全局失败十、观察与评测不要只看最终答案是否“像对的”一边界质量需要一组互补指标1、Context Precision2、Context Recall3、Provenance Coverage 与 Staleness Rate4、Handoff Success 与 Conflict Rate5、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 说明“结果是什么”内容字段说明“结果是什么”控制字段说明“怎样使用这个结果”。例如value500只是内容unitCNY、sourcerule_table_v3、confidence0.90、expires_at...、action_limitproposal_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_version16系统发现当前已是 17便拒绝覆盖并要求重新读取相关字段。这种 Compare-and-Set 思路简单、确定适合高价值状态。对只追加的事件记录则可以并行写入随后由 owner 汇总为新快照。二状态机比自由文本更容易守住业务边界1、关键对象应有有限状态与合法转移例如一个外部方案可以是draft、reviewed、approved、communicated、withdrawn。只有审查通过后才能从 draft 进入 approved只有会话控制器才能进入 communicatedwithdrawn 后不能再次对外使用除非生成新版本。状态机把“能不能做”从 Prompt 提示变成系统约束。Prompt 可以提醒模型遵守流程运行层则必须拒绝非法转移。两者结合比只依赖模型自律可靠得多。2、已对外承诺的状态要特别保护对用户说出口的内容会产生真实预期。它与内部建议不同不应被后台 Agent 轻易覆盖。系统需要一份独立的committed_facts或communicated_offers记录内容、时间、渠道、审批依据和会话证据。后续生成必须先读取这份状态发现冲突时阻断而不是自行“修正历史”。状态更新上半部分用 v1→v2 说明乐观并发检查下半部分说明业务状态只能沿合法路径变化。七、压缩不是写短摘要它是有损信息处理一压缩前先区分必须保真与可以舍弃1、四类内容通常必须保留第一已确认的目标与限制第二已经作出的决定及其理由第三仍未解决的问题与依赖第四关键证据的稳定引用。它们决定后续 Agent 能否保持任务连续性也决定事后能否解释为什么这样做。工具的完整原始返回、重复描述、失败搜索词和不再相关的临时计划通常可以清理。但若失败本身改变了方案例如某个数据源持续不可用则应保留“不可用”这一事实和最后检查时间而不是保留每次失败的全部日志。2、结论可以压证据链不能断一个 20 步分析可以压成三行结论但每一行关键结论都要能回到 Artifact 中的证据位置。摘要负责帮助下游快速判断Artifact 负责保存细节Event Log 负责说明过程。三者互补不能用摘要替代全部记录。二压缩质量要同时看 Recall 与 Precision1、先保住可能影响结果的信息早期调优应优先提高 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 RateHandoff 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 与工具怎样取得数据、调用能力Resource、Tool、Prompt哪些数据可读、结果怎样进入状态Agent 与 Agent怎样发现、委派、更新与交付Agent Card、Task、Message、Artifact业务语义、来源要求、TTL、owner应用内部边界什么信息在何种条件下跨界State Schema、Handoff 数据包、安全门这是系统本身的核心设计十四、进一步判断未来竞争点会从“会协作”转向“能受控协作”一Agent 数量不会成为长期优势更多 Agent 很容易复制可靠边界却来自长期工程积累清楚的数据语义、稳定的状态模型、经过失败案例验证的规则、可回放的事件、校准后的风险门和真实业务评测。系统能力越强边界的重要性越高因为错误动作的影响也更大。二Artifact 会比长对话更接近系统事实未来的 Agent 协作会越来越像软件服务对外暴露能力、任务、成果和状态而把内部实现保持私有。Message 负责协调Artifact 负责交付State 负责共同事实Event 负责解释变化。对话仍然重要但不再承担全部存储和控制责任。三上下文工程最终会成为运行时系统今天很多 Context Engineering 仍依赖 Prompt 和人工经验更成熟的形态会把选择、压缩、来源核对、权限、TTL、版本、撤回和评测写入运行层。模型负责理解开放问题确定性系统负责守住不能出错的边界。十五、结语好的 Multi-Agent 不是彼此知道一切Multi-Agent 的真正难题不是让多个模型开始说话而是建立一套让信息可以被正确使用的秩序。信息太少协作断裂信息太多注意力、成本与风险一起上升。解决这个矛盾的关键是把 Context 从一段不断增长的对话改造成分层、带来源、带时效、带权限、带版本的系统状态与成果网络。一套成熟设计应坚持以下原则先证明任务值得拆分再增加 Agent全局规则、任务说明、共享状态、成果、事件和私有过程分开管理每条跨界信息都经过必要性、来源、时效、权限和风险检查关键状态有单一 owner、版本控制和合法状态转移长结果写入 ArtifactMessage 只带摘要与引用关键动作经过确定性安全门、重复执行保护和必要的人工批准用 Context Precision、Recall、来源覆盖、过期率、冲突率、成本与恢复能力共同评测系统始终保留退回 Single Agent 简单路径的能力。最后可以把全文压成一句话让正确的信息在正确的时点以正确的形式和保证进入正确的 Agent让其他信息留在它应该停留的地方。可参考的文章与规范原始参考文章Multi-Agent 的真问题什么信息该跨越 Agent 的边界ReAct: Synergizing Reasoning and Acting in Language ModelsAnthropic: Effective context engineering for AI agentsAnthropic: How we built our multi-agent research systemA2A Protocol SpecificationModel Context Protocol SpecificationOpenAI Agents SDKMicrosoft AutoGen: TeamsBeyond Self-Talk: A Communication-Centric Survey of LLM-Based Multi-Agent SystemsNIST AI 600-1: Generative AI ProfileOWASP: LLM Prompt Injection Prevention Cheat Sheet