接手这个系列第一篇我想先聊点实在的多智能体系统这东西圈子里聊得火热但从“demo炫酷”到“生产可用”之间横着一条巨大的鸿沟——就是上下文工程。我们团队在把一套基于大模型的multi-agent协作系统真正推到业务线时被提示词工程的老思路反复摁在地上摩擦。你花一周雕琢的提示词在任务稍微复杂一点、Agent一多的时候就像把一整本操作手册塞进一个不识字的人脑子里他每个字都认识但完全不知道该在什么时候调用哪一句。问题的核心在于提示词是“静态配置”而多智能体系统真正需要的是“动态上下文”——每个Agent不仅要理解自己的任务还要知道系统里其他Agent在做什么、做到哪一步了、依赖了哪些结论。这就要靠上下文工程来构建一个透明的架构引擎让推理不再是黑盒。这篇文章要分享的正是我们在这条路上踩过的坑和沉淀下来的方法。内容面向正在做或准备做多智能体系统的工程师、技术负责人以及被提示词天花板卡住手脚的朋友。1. 为什么提示词在多智能体系统里失效了1.1 提示词是静态配置上下文才是运行态先做个类比。提示词工程就像是给一个员工写岗位说明书写得再好也只能描述“你该干什么、按什么标准干、有什么注意事项”。但真实工作场景里员工需要的不只是说明书他需要看板、OA审批流、同事的会议纪要、上游部门传来的半成品。这些动态信息说明书里写不进去也不该写进去。多智能体系统的问题完全一样。每个Agent的提示词定义的是它的“身份”和“行为边界”但Agent之间协作时真正依赖的是任务运行过程中产生的上下文片段——比如第一个Agent调研到的数据、第二个Agent推理出的中间结论、第三个Agent发现的冲突点。这些信息是运行时才产生的不可能预先写死在提示词里。我们最初犯的错误就是试图用提示词去承载这些动态信息把上游Agent的输出全量拼进下游Agent的System Prompt里。结果是什么上下文窗口被塞爆关键信息反而被淹没在无关噪声里。更麻烦的是Agent对同一个上下文的解读经常不一致因为没有任何机制约束“这一段话到底代表什么”。1.2 多智能体系统的三类上下文你分清楚了吗和单体Agent不同多智能体系统的上下文至少可以拆成三层任务上下文Task Context原始需求、约束条件、交付标准。这些通常来自用户或上游业务系统属于相对静态的输入。协作上下文Inter-Agent ContextAgent之间传递的中间结果、依赖关系、执行状态。这是多智能体系统独有的也是最容易失控的部分。系统上下文System Context运行环境的全局信息比如可用工具、调用配额、全局优先级、安全策略。它约束着所有Agent的行为边界。很多翻车的多智能体架构就是把这三层上下文混在一锅粥里统统塞给每个Agent。结果每个Agent都以为自己是“总控”导致决策冲突、重复劳动、互相覆盖结果。我见过一个实际案例一个外贸自动化系统里负责“市场调研”的Agent把竞争对手分析和目标客户画像都塞给负责“邮件撰写”的Agent邮件Agent同时收到三十多页调研材料根本分不清哪些是事实数据、哪些是Agent自己的推断。最后生成的邮件里把“竞争对手的市场份额数字”直接当成“我方优势”写了进去。这不是提示词没写清楚而是上下文没有分层、没有标记来源和可信度。1.3 上下文工程的本质从“写好提示词”转向“设计信息流”上下文工程Context Engineering这个概念的提出本质上就是把注意力从“怎么写指令”转移到“怎么构建、管理和传递信息”。提示词只是上下文的一部分远不是全部。一套合格的上下文架构至少要回答三个问题每个Agent在运行时需要哪些上下文这些上下文从哪里来是用户输入、其他Agent产出还是系统状态上下文在Agent之间流动时如何保证不被误解、不丢失关键信息、可回溯把这些问题落到工程上就需要一个“透明架构引擎”——它管的不只是“让Agent输出正确答案”而是让整个系统的推理过程变得可见、可控、可审计。这也是这个系列的核心主线构建上下文与推理的透明架构引擎。2. 透明架构引擎的总体设计思路2.1 四层结构采集、编排、推理、评估我们在实践中沉淀出的引擎架构分成了四层每层职责单一彼此通过标准接口通信上下文采集层负责从外部系统、用户输入、数据库、API等来源收集原始上下文做清洗、标准化和初步结构化。上下文编排层核心层。决定哪些上下文片段需要送给哪个Agent、以什么顺序送、哪些可以并行、哪些必须串行。推理执行层各个Agent真正干活的地方。它们接收到编排层打包好的上下文产生输出再把输出回传给编排层。评估反馈层对整个流程做质量监控——上下文是否充分、Agent的推理是否偏离目标、有没有上下文冲突。层与层之间只通过结构化消息交互不共享可变状态。这个设计决策是关键。很多团队做多智能体时会贪图方便让所有Agent直接读写同一个全局内存或数据库刚开始跑得挺顺一旦任务量上来各种脏读、覆盖、锁竞争问题会让人怀疑人生。按我的经验编排层一定要维持一个上下文存储Context Store但Agent不能直接访问它只能通过编排层提供的接口去读写。这看起来多了一层转发但换来的是谁在什么时候读了什么、改了什么全部有记录。出现问题时可以直接回放整个上下文的演变过程。2.2 核心概念上下文票据Context Ticket这是整个引擎里我们觉得最值得讲的设计。每个上下文片段不是裸数据而是被封装成一个“票据”Ticket类似你在园区里看到的工单系统里那种单子。一张票据包含上下文ID全局唯一的标识。来源Agent或来源系统表明这段信息是谁产生的。内容摘要与结构化字段不仅有大段文本还能带结构化数据JSON、表格。时间戳与版本号记录产生时间和当前版本。可信度标记是“原始事实”、“模型推断”、“待验证假设”还是“人工确认”。关联票据ID如果是基于其他票据推导出来的就建立血缘关系。为什么要搞得这么重因为多智能体系统的信息失真往往发生在传递过程中。当一个Agent产出的结论要经过另一Agent加工时如果只是把文本原封不动传过去接受方很容易把“推断”当成“事实”用。有了票据和可信度标记下游Agent就能判断“这段话我只能作为参考不能作为决策依据”。我举一个具体例子。假设系统里有A和B两个AgentA负责收集行业数据B负责制定市场策略。A输出的票据上标记着“两个竞品的市场份额数据来自第三方报告可信度标记为中等存在统计口径差异”。B读到这个标记就会在推理时对这些数据多加一层谨慎不会再像以前那样直接拿来做精确计算。这种“元信息”的传递靠提示词根本做不到必须靠上下文工程的结构化设计来支撑。2.3 双层记忆Agent私有记忆与共享记忆多智能体系统的记忆管理是个大坑。一开始我们让每个Agent都记住全部历史对话效果很差上下文窗口被历史对话占满真正有用的业务信息反而挤不进去。后来改为严格区分私有记忆每个Agent维护自己的对话历史、中间推理草稿、局部观察。这些内容对其他Agent默认不可见。共享记忆只有经过编排层批准并写入上下文存储的内容才允许其他Agent读取。这个约束非常反直觉——很多做多Agent框架的人会反问既然要协作为什么还要藏私有记忆答案在于信息隔离本身就是一种保护机制。Agent在私有记忆里的推理草稿往往是噪声很大的如果这些解码过程中的半成品被其他Agent捡去用了就会造成错误传播。只有经过编排层“审定”的结论才能进入共享记忆。好比一个公司里员工之间讨论时的随口猜测、吐槽、脑洞不应该直接进入正式会议纪要只有经过负责人确认的结论才能同步给跨部门协作伙伴。这个类比虽然有点俗但在系统设计逻辑上完全一致。2.4 推理进程可视化引擎的“透明”体现在哪透明架构引擎的另一个核心能力是把Agent的推理路径暴露给开发者。我们做了一个“推理视图”运行中的每个Agent都会上报自己当前的状态正在处理哪个票据、参考了哪些前置票据、打算输出什么结论、置信度是多少。这个视图解决了多智能体系统里最折磨人的问题——不确定性。单体Agent出错时你看一看它的prompt和输出就能大致定位原因。多Agent系统出错时错误可能发生在任何一跳传递或加工过程中。没有推理视图排查问题就像在黑灯瞎火的迷宫里找一条断掉的铁丝全靠猜。有了推理视图我们可以做两件事一是实时干预发现某个Agent带着错误的中间结果越走越偏时及时下发修正指令二是事后复盘任务结束后把整个推理链路导出来逐段分析哪里出了岔子。这套方法我们在一次供应链预测项目里把一个失败任务的定位时间从四小时缩短到了二十分钟。3. 设计上下文与推理的透明架构引擎3.1 任务上下文如何做结构化拆解在开始搭建引擎前要把任务的上下文拆成结构化的片段。先定义一次会话的开始外部输入进来后先做什么将用户需求抽取为“目标片段”包括核心目标、约束条件、允许使用的工具、不允许触发的行为。这些都是二元化的判断便于Agent遵循。再通过与用户或上游系统的多轮交互把这些信息补全成一个统一的“任务通告”。你可以把任务通告当成整个多智能体系统的“宪法”——所有Agent读同一份任务通告只能基于它行事。每个Agent在执行时还可以产生自己的“执行子计划”但要向上汇报。“宪法”式任务通告的优势是如果发生上下文冲突所有Agent有一个统一的裁决参考。不产生二义性但也要防止Agent完全被约束。所以我们在通告里留了“自由裁量区”比如“在达到目标的前提下执行方法允许不同”。3.2 上下文结构化信息模型我们把每种类型的上下文都用一个Kind来表示这些Kind都会在Topic属性里有明确标识。例如Input: 用户输入即任务通告本身。Intention: 从用户输入里抽取的意图。Fact: 来自外部系统数据库、API、文档的数据事实。Inference: Agent产生的推断结论可信度未定。Hypothesis: 假设、候选方案待验证。Decision: 确认后的最终决策作为后续Agent执行的输入。Requirement: 任务约束或验收条件。Meta: 系统自身的元信息例如来源、版本。每一种Kind都会映射到一种处理策略。比如Fact可以进入共享存储供多个Agent引用Hypothesis只能由提出它的Agent自行消费若要被其他Agent使用必须升级为Decision或Inference。这样做的根本目的是让“数据血缘”在全链路中可追踪。什么数据能影响决策一目了然。3.3 票据与血缘让“推理依据”可追溯透明架构里至少两张核心表要设计好上下文存储表Context Tickets所有票据存储维护其内容、来源、状态。推理轨迹表Trace每次Agent执行都记录输入票据ID列表、输出票据ID、Agent名、执行时间、关键超参。比如Agent C收到票据T1和T2执行完输出T3那么Trace里会记录T3的前驱是T1和T2后继是T4。这样当最终结果T9出了问题你可以沿着Trace做反向BFS找出影响该结果的所有票据链然后定位是在哪个Agent开始出现偏离的。实际项目里我们还做了一个小工具把Trace渲染成树状图每个节点对应一个票据边对应Agent的加工关系。这张图就是“推理的可视化”。它除了排查问题还有一个意外收获——给业务方看。领导或客户不再关心你的prompt写得精不精妙他们只关心“这个结论是怎么得出的依据靠不靠谱”。你能拿出一张推理链图谱比解释半天架构都有效。3.4 推理网关控制Agent何时、以何方式推理多智能体系统常常陷入一个尴尬局面任务被分解到多个Agent后每个Agent都以为自己马上要动手结果系统在不需要的地方进行了大量无效推理。我们增加了推理网关Reasoning Gateway概念上类似API网关所有Agent调用模型前必须过网关。网关做的事情有三件准入控制当前上下文的票据是否足够支撑该Agent开始干活如果缺关键票据直接返回“等待上游”不发模型请求。策略路由根据任务类型选择合适的模型。简单复述类任务走小模型深度推理类任务走强模型。这一步对成本控制尤其重要。超时控制与降级Agent推理超时后网关可以选择重试、切换模型或者直接返回部分结果。这个网关看起来像基础设施但实际它对“透明性”有巨大贡献每一个模型请求都经过网关你就能在网关层统一记录每次推理的输入票据、输出内容、模型版本、tokens消耗。没有网关时各Agent直接调模型日志散落各处审计时根本没法搞。4. 实操参考一个最小上下文引擎的落地过程4.1 选择场景与引擎边界搭建多智能体上下文引擎必须用一个“足够日常又足够暴露问题”的场景来验证。我们选用了一个内部非常常见的场景跨部门技术方案评审。流程涉及三个角色情报员Researcher负责收集资料并输出结构化摘要。分析师Analyst基于情报产出方案并做风险评估。合规官Advisor负责审查方案是否满足安全与合规要求。这个场景天然有多跳传递、多方协作、单一信息源隔离等特征非常适合验证上下文工程。4.2 引擎配置定义角色、上下文流动路线在设计引擎时不建议把这些角色直接写成三个互相调用来回传大量文字的Agent而是用编排层定义一条“流水线”平台收到用户需求后情报员先执行输出一份“资料调查票据T1”。编排层确认T1充分再唤醒分析师给它T1和任务通告输出“草案票据T2”。合规官接收T2和T1进行审查输出“合规审查票据T3”。编排层汇总T1、T2、T3生成最终交付视图给用户。流水线的每个节点都只获取它依赖的哪怕是较少的一部分票据而不是全量上下文。这是上下文工程的基本原则按需供给而非无限堆料。4.3 配置文件和上下文流定义参考一段我们在引擎里用YAML来定义这条流水线。大致结构如下pipeline: name: requirement_proposal_review stages: - agent: researcher name: 资料调查 requires: - task.intention output_role: fact.source_summary allowed_tools: - web_search - doc_reader wait_for: [] - agent: analyst name: 草案设计 requires: - intention - fact.source_summary output_role: decision.draft_plan wait_for: [researcher] - agent: advisor name: 合规审查 requires: - decision.draft_plan - fact.source_summary output_role: decision.compliance_review wait_for: [analyst] - aggregator: summary name: 结果汇总 requires: - decision.compliance_review - decision.draft_plan - fact.source_summary这里值得强调的是wait_for字段。它显式声明了依赖顺序防止Agent在缺少前置条件时提前开工。第一次搭建时我们图省事没有定义这个字段结果系统刚上线就出现情报员还没返回分析师就开始基于空上下文生成草案的笑话。别省这一步。4.4 核心代码上下文票据的流转与管理用Python实现一个轻量的引擎原型可以这样组织票据类和编排逻辑from dataclasses import dataclass, field from typing import Optional from enum import Enum import uuid import datetime class TicketKind(str, Enum): INTENTION intention FACT fact INFERENCE inference DECISION decision REQUIREMENT requirement dataclass class ContextTicket: ticket_id: str field(default_factorylambda: str(uuid.uuid4())) kind: TicketKind TicketKind.FACT content: str producer_agent: str created_at: str field(default_factorydatetime.datetime.utcnow().isoformat) parents: list field(default_factorylist) confidence: float 1.0 trusted: bool True class ContextOrchestrator: def __init__(self): self.store {} self.traces {} def submit_ticket(self, ticket: ContextTicket): self.store[ticket.ticket_id] ticket self.traces[ticket.ticket_id] { producer: ticket.producer_agent, parents: ticket.parents, timestamp: ticket.created_at, } def query_ticket(self, ticket_id: str) - Optional[ContextTicket]: return self.store.get(ticket_id) def trace_lineage(self, ticket_id: str): lineage [] queue [ticket_id] while queue: current queue.pop(0) ticket self.store.get(current) if not ticket: continue lineage.append({ ticket_id: current, producer: ticket.producer_agent, kind: ticket.kind, }) queue.extend(ticket.parents) return lineage这段代码的核心价值不是功能多强而是明确了三个原则每个票据不可变创建后不修改、血缘关系通过parents字段显式记录、编排器是票据存取的唯一出入口。在真正的工程实现中store要换成PostgreSQL或Redistraces要用时序数据库存但抽象逻辑是一样的。如果一开始就上重框架很容易迷失在存储选型和接口设计里反而忽略上下文流转这个核心问题。4.5 检验“透明性”的三个基本指标搭好最小引擎后怎么知道自己做对了没有我们内部总结了三个指标追溯完整性最终交付结果的每一个关键断言是否可以100%追溯到产生它的Agent和原始票据数据血缘断点要低于预设阈值理想是零。上下文独立验证任意一个Agent能否在完全不知晓其他Agent私有记忆的情况下单凭接受的关键票据完成推理如果不行说明编排层泄露了不必要的上下文。故障可定位性人为注入一个错误票据比如把情报员的数据篡改能否在限定时间内由人工或自动监控工具定位到错误源头这三个指标分别对应透明架构引擎的“完整性”“隔离性”“可控性”。我们内部每周会跑一次故障注入演练效果显著。有一次测试人员故意把一个分析师生成的草案标记成“已合规”不设防的情况下系统在两天后才被发现3%的数据被CTA写进了对外文档。引入血缘追踪和下游验证节点后这个时间缩短到几分钟。5. 常见问题与排查技巧实录5.1 上下文漂移Agent答非所问的元凶多Agent系统运行时间越长越容易出现“上下文漂移”——Agent开始偏离原始任务目标。典型症状是情报员输出的报告充满与题目无关的二手案例或者分析师把注意力集中在某一句细节上忘了大局。根因往往不是提示词写歪了而是任务通告在系统运行中被间接“污染”了。比如上游Agent在传递给下游时把通告里一段“仅供参考”的建议改写成了“用户明确要求”。排查手段对比下游Agent实际接收到的票据内容与原始任务通告在编排层做一次差异审计。我们会在每个Agent的输入票据上打一个对标哈希任务通告的哈希值在整个流水线里必须保持一致任何改写都会造成哈希不匹配触发告警。5.2 Agent之间的“鸡同鸭讲”多个Agent对同一事实的理解不一致是协作中最典型的问题。比如A说“市场份额”指的是金额占比B理解成出货量占比两者的结论就会打架。深层原因是票据缺乏共识性的字段定义。解决方式很朴素上下文票据里增加语义类型Semantic Type或值域枚举Value Enum甚至共享一个全局概念表。你可以把概念表也做成一个票据由编排层定期维护。如果实在来不及最低成本的兜底方案是在票据内容前加一句数据口径说明比如“【口径】本数据为2024年Q2全球市场数据单位亿元人民币来源第三方行业报告”。这一个动作就极大降低了“鸡同鸭讲”的概率。5.3 推理循环与嵌套多Agent系统“死锁”问题你可能会遇到Agent A等待B的输出才能继续而B又等待A的某个审批结果形成循环依赖。对这在就是多Agent系统里最常见的死锁。不是每个Agent单独有问题而是编排层的依赖关系设计出现了环。要根治必须在编排层做依赖图的拓扑排序。我们在流水线定义里就要求wait_for字段必须构成有向无环图。每次启动新任务时会先对依赖图做一次检测发现环就直接拒绝任务启动并返回报错不让问题拖到运行时。如果实在无法避免循环依赖某些决策类任务天然是迭代式的就把环显式设计成“人工审批节点”来断环。让一个人类管理员介入承担裁决角色。这样做不但解决死锁还顺便增加了系统的可信度。5.4 成本失控上下文堆料让Token翻倍多智能体系统比单体Agent的Token消耗大得多这点不用怀疑。单体Agent一次推理的输入可能就是几K Token多Agent系统里一次任务可能要经历5到10次推理每次还带着上下文。成本翻5到10倍太正常了。我们踩过的坑就是贪婪传递每个Agent都把接收到的全部上下文原封不动传给下游。后来改为每个Agent只能输出“最小充分结论”到共享上下文下游需要更多细节时可以通过票据ID主动查询原始数据。也就是改“推”为“拉取”。这个最简单的变更让系统Token成本下降了约40%推理延迟也明显降低。5.5 问题排查速查表问题典型症状首要排查方向常用手段上下文漂移Agent答非所问、偏离目标任务通告是否被改写哈希校验、血缘审计语义冲突Agent结论互相矛盾数据口径是否有差异语义类型、口径标注、概念表死锁系统卡住不产出依赖图是否有环拓扑排序校验、人工断环成本飙高Token消耗异常增长是否全量推送给下游最小结论输出、按票据ID按需拉取错误传播错误从某个中间结果扩散溯源到变质票据可信度标记、上游重跑校验推理链路断裂无法定位出错节点Trace路径是否完整推理轨迹表、血缘反查、降级重放6. 写在最后的一点体会这个系列开篇我只讲了一个核心观点多智能体系统的工程化不是把多个提示词拼在一起而是需要一套能把上下文组织起来、流动起来、并让推理过程变得透明的架构。上下文工程不是取代提示词工程而是它的下一级基建。提示词仍然重要但它从“主角”变成了“底座”——真正的控制力来自上下文的结构化设计、血缘追踪与编排治理。按照我们团队的经验从“提示词思维”切换到“上下文思维”这个转变过程大约需要三到四周的实践才能真正理解。第一次做上下文票据拆分时你会觉得很繁琐好像在写文档而不是在写代码但当你因为一张票据远溯到三跳之外的错误源头时你就会开始感激这种繁琐。下一篇我会展开讲推理轨迹与血缘机制的实战设计包括Trace数据模型、跨Agent的链路持久化方案以及错误注入测试的具体做法。如果你正在做多智能体系统也遇到过上下文混乱、推理黑盒、或者Agent间协作失序的问题欢迎带上具体场景来交流。