角色边界Planner定义任务Worker交付Artifact和证据Reviewer负责验收编排器执行硬约束。但角色拆开以后系统才刚开始变复杂。三个Agent如果复制同一份聊天记录、把并行结果按返回时间拼接、允许子Agent继续无限派生角色虽然分开了上下文、状态和预算却还是一锅粥。这篇就解决一个问题多Agent跑起来以后怎么让每个Agent只看到该看的信息让消息可追踪、可去重让Token在失控前被系统截住。面试官会怎么问“你们多个Agent之间怎么传上下文并行消息怎么保证不乱序子Agent还能创建子Agent时怎么防止Token爆掉”很多录友会回答“主Agent把历史发给子Agent子Agent完成后把结果传回来上下文太长就做摘要Token超了就停止。”这个回答的问题很具体。**第一完整复制历史会把角色污染掉。**Worker会看到与当前任务无关的讨论、其他Worker的猜测和过期工具结果不仅浪费Token还可能把未经验证的内容当成事实。**第二按返回时间拼消息会破坏因果。**并行任务谁先完成只代表谁更快不代表它应该先被消费。重试还可能把同一结果送两遍。**第三超限后才停止已经太晚。**多个子Agent并发执行时如果没有预留和原子扣减每个Agent都以为预算还有剩余总消耗很容易一起穿透上限。面试官真正想听的是上下文怎样隔离和按需组装事件怎样标识因果与幂等预算怎样分配、回收、降级和熔断。简要回答**每个Agent使用独立Thread。**子Agent不继承完整聊天只接收结构化任务包、必要约束、依赖Artifact引用和本任务工具。**大结果放Artifact Store。**消息只传状态、摘要、证据引用和版本不在线程之间反复复制日志、网页和代码全文。**消息顺序按因果关系处理。**单个Agent用seq_no保序跨Agent用task_id、DAG依赖和parent_event_id判断谁依赖谁不按墙上时钟强行排成一条总序列。**预算由编排器统一记账。**派发前预留子任务额度运行中同时限制输入、输出、工具结果、重试、步数和时间不能让Agent靠Prompt自觉省Token。**递归派生默认关闭。**必须开启时限制最大深度、子节点数量和祖先环并让子Agent的额度从父Agent剩余预算中分配。**不同任务走不同模型。**摘要、分类、格式转换可以路由到小模型复杂规划、最终合成和高风险审查再使用强模型但路由必须经过评测。多Agent治理不是把一个大上下文切成几份而是把对话变成独立工作区把协作变成带因果的事件把Token变成可预留、可回收的资源。多Agent上下文治理链路这张图回答的是一个子任务从编排器派发到最终汇总如何通过独立Thread隔离过程、通过Artifact与事件引用交接结果并让所有并行分支共同受全局预算和递归边界约束。为什么多个Agent不能共享一条消息历史假设主Agent要完成一份线上故障报告同时派出三个WorkerWorker A查监控Worker B查日志Worker C查发布记录。如果三个Worker共享一个messages数组A返回的几千行指标、B返回的错误堆栈、C看到的版本信息会不断混在一起。问题不只是“窗口容易满”。A的一句“可能是连接池问题”会进入B的上下文B后面更容易围绕这个假设找证据C的一次工具超时也可能被其他角色误解为“没有发布记录”。共享历史会让并行探索变成相互暗示多个Agent看似独立错误却高度相关。多Agent共享历史混乱更稳的做法是每个Agent维护独立Threadroot thread├── worker-a thread任务包A A的工具调用 A的局部状态├── worker-b thread任务包B B的工具调用 B的局部状态└── worker-c thread任务包C C的工具调用 C的局部状态独立Thread不是完全断开联系。编排器知道它们属于同一个run_id也知道每个子任务的父节点和依赖只是它不会把一个Agent的完整过程自动广播给所有人。如果B确实需要A的监控结论编排器传的是经过验收的Artifact引用而不是A从第一轮到最后一轮的全部对话。这和《Context Engineering入门》里的原则一致**给当前推理最少但足够的高信号信息。**多Agent只是把这个原则从“一个窗口怎么编排”扩展到了“多个窗口怎么隔离”。子Agent到底应该收到什么子Agent收到的不是父Agent聊天记录而是一份可校验的任务包。{ run_id: incident-20260908,task_id: inspect-payment-logs,parent_task_id: find-root-cause,goal: 检查22:00至23:00支付服务错误日志,acceptance_criteria: [给出错误峰值时间, 结论附日志证据引用],context_refs: [artifact://release-record/v2],allowed_tools: [search_logs, read_trace],output_schema: worker_result_v1,budget: {max_input_tokens: 12000, max_output_tokens: 2000, max_steps: 8},deadline_ms: 45000}组装子Agent上下文时可以固定成六层不可覆盖的全局安全规则当前角色的职责与禁止项当前任务包已通过依赖的Artifact摘要与引用当前任务允许使用的工具Schema剩余步数、时间和Token预算。父Agent的语气、闲聊、完整思考过程以及其他分支尚未验收的猜测都不应该默认继承。如果任务缺信息子Agent要返回BLOCKED和缺失字段由编排器补充或退回Planner。不要为了让子Agent“更懂背景”先把所有历史都塞过去。为什么消息里只传引用不传完整产物一次日志查询可能返回5万行一次代码检查可能产生上百KB的Diff。这些内容如果从Worker复制给Reviewer再从Reviewer复制给主Agent同一份材料会重复进入多个上下文。Agent越多Token复制越严重。所以要把“消息”和“产物”拆开消息负责协调任务状态、简短摘要、失败原因、证据引用Artifact负责承载内容报告、补丁、日志快照、测试结果、结构化数据事件日志负责审计谁在什么时候基于哪个版本做了什么判断。Worker的完成消息可以很小{ event_type: TASK_COMPLETED,task_id: inspect-payment-logs,status: completed,summary: 22:14起第三方回调超时集中升高,artifact_refs: [artifact://payment-log-analysis/v3],evidence_refs: [trace://log-query/8841],unresolved: [22:14至22:16网关日志缺失]}Reviewer需要细节时再按引用局部读取对应段落或证据。这里有一条底线**摘要可以帮助定位不能替代原始证据。**Artifact必须带版本、内容哈希或不可变快照不能让Reviewer验收v3时底层内容已经悄悄变成v4。并行消息怎么保证不乱序多Agent系统通常不需要一个“全局绝对顺序”。Worker A在10:00:03完成Worker B在10:00:02完成并不能说明B的结果应该先进入汇总。真正重要的是B是否依赖A某条消息是否是另一条消息触发的以及同一任务内部事件的先后关系。一个最小事件信封可以包含{ event_id: evt-9382,run_id: incident-20260908,task_id: inspect-payment-logs,agent_id: worker-log-02,seq_no: 7,parent_event_id: evt-9310,idempotency_key: inspect-payment-logs:completed:v3,event_type: TASK_COMPLETED,artifact_refs: [artifact://payment-log-analysis/v3]}这几个字段各管一件事字段解决的问题run_id把同一次用户任务的事件串起来task_id、agent_id定位事件属于哪个子任务和执行者seq_no保证单个Agent线程内部顺序parent_event_id记录“谁触发了谁”的因果关系idempotency_key重试或重复投递时避免重复写入和重复汇总artifact_refs指向确定版本的产物不复制正文编排器收到事件后不是立刻把它拼进主Prompt而是先做三步用event_id或idempotency_key去重检查seq_no是否连续缺号就暂存并等待或补拉检查DAG依赖与parent_event_id依赖满足后才推进状态。同一个Agent的seq_no8先于seq_no7到达可以暂存在Inbox里两个互不依赖的Worker同时完成则都标记成功等汇总节点的前置条件全部满足后再触发。**不要用时间戳代替因果关系。**分布式环境会有时钟偏差、网络延迟和重试谁先到不等于谁先发生更不等于谁先被业务消费。Token预算为什么要在派发前预留很多系统有max_tokens却依然会超预算因为它只限制了一次模型输出。多Agent真正消耗的是一整棵任务树多Agent预算闸门总消耗 根Agent输入输出 所有子Agent输入输出 工具结果进入上下文的Token 重试与返工 最终汇总和验收如果总预算是100K根Agent同时派出4个“最多30K”的Worker理论上限已经到120K还没有给Reviewer和最终回答留额度。因此预算要像并发系统里的资源配额一样管理。派发子任务时编排器先从父任务的可用额度里原子预留一块预算。预留成功才启动预留失败就缩小任务、排队、换模型或拒绝派生。任务结束后未使用的额度再回收到父任务。可派发预算 全局上限 - 已消耗 - 已预留 - 根流程保底 - 验收保底这不是精确预测模型一定花多少Token而是防止多个并行分支同时把同一份余额算给自己。预算也不能只管输出Token。至少要同时限制单次和累计输入Token单次和累计输出Token工具结果返回大小与分页次数模型调用次数、工具调用次数和重试次数子Agent数量、递归深度和任务总时长。关于输入、输出、成本和延迟之间的基础关系可以先看《Token、成本与延迟》。预算快用完时怎么降级预算治理不是“用完就报错”而是提前分级收束。下面是一组示例阈值不是行业标准实际值要根据任务风险和评测结果调整预算水位系统动作0%—60%正常执行仍受单节点上限约束60%—80%禁止低价值扩展压缩旧工具结果优先复用Artifact80%—95%停止新建非关键子Agent小任务切换到低成本模型95%以上强制收束保留验收与最终回答额度返回部分结果或升级人工压缩也有边界。聊天过程和重复日志可以压缩订单号、文件路径、错误码、验收标准与原始证据引用不能被“概括掉”。高风险任务宁愿少做一个分支也不要把验证预算拿去继续探索。**预算应该优先保护最终合成和验收。**Worker全都跑完Reviewer却没有Token可用这个任务仍然不能算完成。子Agent还能创建子Agent怎么办默认答案是不允许。Worker发现任务需要继续拆分可以返回Planner重构DAG。只有层级任务确实需要局部自主拆分时才开放受限派生能力。一旦开放至少加四道硬限制max_depth最大递归深度max_children每个节点最多创建几个子节点ancestor_task_ids记录祖先链禁止A派生B、B又派生Achild_budget parent_available_budget子节点只能花父节点分出的额度。还要限制“同义派生”。有些Agent不会创建完全相同的任务ID却会连续创建“继续搜索”“补充搜索”“深入搜索”。编排器可以用规范化目标、输入范围和工具集合生成任务指纹相似任务超过阈值就拒绝避免换个名字继续烧钱。这部分和《Agent为什么容易翻车》里的循环控制是一回事自由派生必须有深度、宽度、相似任务和预算四重停止条件。模型路由怎么和预算配合不是每个角色都必须使用最强模型也不能简单规定“Planner用大模型Worker用小模型”。路由至少看三个维度任务复杂度抽取、分类、格式转换通常更适合小模型开放规划和冲突合成需要更强推理风险等级涉及生产写操作、权限和合规时模型能力之外还要增加规则校验或人工门禁可验证性输出能被Schema、测试或数据库规则直接验证时可以更积极地使用低成本模型。一个实用做法是先让离线评测回答“这个任务类型由小模型执行质量下降多少节省多少Token和延迟”如果小模型输出变短了却导致返工次数翻倍总成本可能更高。模型路由看的是单个合格任务成本不是单次调用价格。出错以后怎么恢复而不是整棵树重跑上下文、消息和预算治理最终都要落到恢复能力上。如果Worker超时编排器应该保留它已写入的Artifact和最后确认的事件序号再决定从Checkpoint重试、换模型、缩小任务还是降级交付。如果消息重复只做幂等确认不重复触发Reviewer。如果Artifact版本不一致只让受影响的汇总节点重新执行不推翻已经通过的无关分支。如果全局预算触发熔断则冻结新派生取消非关键运行节点把剩余额度留给状态总结和部分结果交付。这依赖《Plan-and-Execute怎么落地成DAG执行器》里的状态机与Checkpoint。没有持久化状态所谓“重试”往往只是把整段昂贵流程再跑一遍。怎么验证治理真的有效只看最终回答对不对不够。至少监控六组指标上下文各角色输入Token、重复Token比例、Artifact局部读取命中率消息乱序暂存数、重复事件率、幂等冲突率、依赖等待时间预算预留量、实际消耗、回收量、各角色占比、熔断次数递归任务树最大深度、分支数、相似任务拒绝次数质量任务完成率、首次验收通过率、关键约束保留率业务效率P95延迟、单个合格任务成本、人工接管率。还要拿单Agent做基线。如果多Agent让总Token翻了三倍任务完成率只提高一点说明拆分粒度或上下文交接有问题如果Token下降但关键约束丢失说明摘要压缩过度如果成本可控但乱序等待很高可能是DAG依赖设计得太重。治理不是让指标都越低越好而是让质量、成本和延迟的交换关系可解释、可预测。面试时怎么讲可以这样回答我们不会让多个Agent共享同一条消息历史而是给每个Agent独立Thread。编排器只下发当前任务包、已通过依赖的Artifact引用、允许工具和预算不复制父Agent的完整聊天。大结果写入带版本的Artifact Store消息只回传状态、摘要和证据引用。每条事件带run_id、task_id、agent_id、seq_no、parent_event_id和幂等键。单线程按seq_no保序跨Agent按DAG依赖和父事件判断因果重复投递不会重复推进状态。Token由编排器统一记账。派发前从父任务余额中原子预留未使用额度可以回收预算接近上限时先停止非关键派生、压缩旧结果、切换低成本模型最后保留验收和收束额度。递归默认关闭开放时限制深度、分支、祖先环和子任务预算。这套回答比“把上下文传过去超了就截断”多出的正是生产系统需要的隔离、因果、幂等和资源治理。知识拓展多个Agent一定要用消息队列吗不一定。任务量小、进程内执行时数据库状态表加内存调度器也能完成。消息队列解决的是异步投递、削峰和消费者解耦但无论用什么基础设施事件ID、幂等键、因果字段和状态机都不能省。seq_no能不能保证跨Agent顺序不能。seq_no只对某个Agent或某个任务流有意义。跨Agent应该看DAG依赖和parent_event_id互不依赖的事件不需要强行决定谁是第一。Prompt Cache能不能解决多Agent Token成本它可以减少稳定前缀的重复计算或费用但不能替代上下文治理。被缓存的无关内容仍可能占窗口并稀释信号大型工具结果和跨角色历史也不会因为缓存就自动变得有用。Artifact和长期记忆有什么区别Artifact是当前任务产生、可版本化和可验收的工作产物长期记忆是跨任务保存的用户偏好、稳定事实或经验。Artifact不能自动写成长期记忆是否保留仍要经过《Agent的记忆》里讲的写入门槛、过期和冲突治理。为什么不能让Agent自己决定还剩多少预算模型只能看到系统告诉它的数据也无法和其他并行分支完成原子记账。它可以建议压缩或停止但真实余额、预留、扣减和熔断必须由编排器执行。写在最后多Agent最危险的不是某个Worker答错而是错误历史被复制、重复消息被执行、并行分支同时把预算花穿。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】