最近我看“智源TALK”第389期时标题第一眼就抓住了我从个体智能到系统智能。这句话其实戳中了过去半年多智能体领域最核心的痛点。单Agent大家已经玩得很溜指令遵循、工具调用、代码生成都能做到七八十分但一旦把三五个Agent串成一个系统问题就全来了——上下文互相污染、A等B而B等A、某个Agent的幻觉顺着消息链扩散到全局。这期Talk用Graph Engineering这个视角重新组织了整个多智能体的技术栈我认为这是目前最接近工程落地的一种思考方式。这篇文章我会站在一个做Agent平台架构的工程师视角把Graph Engineering到底是什么、它解决了多智能体哪些核心痛点、以及我们在实际搭建这种系统时最容易踩的坑完整展开说一遍。适合正在做多智能体落地、准备引入Agent协作框架的读者也适合想了解Agent系统怎么从“能跑demo”到“能上生产”的技术负责人我会把关键组件、选型逻辑、排查手段和协作规范都覆盖到。1. 从个体智能到系统智能多智能体演进的必然与阵痛1.1 为什么单个Agent撑不住复杂任务先说个最直观的现象。我见过不少团队做的单Agent应用能力确实不错你给它一个代码仓库它能帮你定位问题、改代码、写测试你让它分析一份财报它能输出结构完整的报告。但这类应用有个共同的天花板——当任务本身需要多个角色、多个视角、多轮验证时单个Agent的上下文窗口和单步推理能力就明显不够用了。举个例子我们早期做过一个代码审查Agent。单Agent方案里它既要读需求文档、又要读代码、还要检查安全规范和性能隐患。结果它一会儿输出“这段逻辑没问题”一会儿又对同一个函数给出完全相反的修改建议。后来我们才发现问题不在于模型能力而在于所有职责混在一个上下文里模型很难同时保持“需求理解者”“代码审查者”“安全专家”三重角色的一致性。这就是从个体智能走向系统智能的最根本驱动力任务复杂度超过了单个决策单元的承载能力必须让多个Agent各司其职。1.2 系统智能不是“人多力量大”而是结构化协作很多人看到多智能体第一反应是“多开几个Agent并行跑总有一个能给出正确答案”。真做起来完全不是这么回事。多Agent系统要涌现出真正的“系统智能”必须同时满足四个条件分工明确每个Agent有独立的职责边界和决策空间不能所有Agent都在处理相同的完整上下文信息互通Agent之间需要共享任务进展、中间产物和约束条件但共享粒度要可控冲突仲裁多个Agent给出不同结论时系统需要有裁决机制而不是把冲突结果直接暴露给用户状态一致整个流程的当前状态必须是可追溯的任何时刻都知道“任务走到哪一步、哪一步由谁产出”你会发现这四个条件本质上全是结构问题不是模型问题。它们关系到Agent之间的连接关系、数据流向、状态存储和任务时序而这些恰好是图结构最擅长表达的。Graph Engineering就是在这个背景下被推到前台的。1.3 Graph Engineering不等于知识图谱这里要先澄清一个常见的误解。很多人一听“Graph Engineering”首先想到知识图谱、GraphRAG以为是给Agent加一个图数据库做记忆。这确实是图工程的一部分但不是全部。在智源TALK的框架里Graph Engineering是把整个Agent协作系统本身建模成一张图节点是Agent或工具边是消息流、控制流和状态依赖图的拓扑决定协作逻辑图的状态决定系统行为。我之前也是被这个命名迷惑过后来在做架构设计时才真正理解它的价值。用图来管理多智能体系统带来的是三个层面的收益协作关系可视化、流程时序可编排、故障定位可追踪。这三个收益直接对应了多智能体从实验室走向生产最需要的三个能力。所以我后面所有展开的技术点都是围绕着“把Agent系统当作一张有状态的图来工程化”这条主线。2. Graph Engineering技术全景拆解核心组件与设计原理2.1 图拓扑设计决定你的系统是“流水线”还是“决策网络”图工程的第一步是设计拓扑。目前主流的Agent协作拓扑可以归成三类它们在工程实现上差异很大拓扑模式结构特征典型场景工程难度流水线Pipeline/DAG有向无环图消息单向流动数据清洗、文档生成、CI/CD式任务流低逻辑清晰层级协作Hierarchy监督者Agent调度多个工作Agent代码开发、团队协作、复杂项目拆解中需要仲裁机制动态路由Router/Planner根据任务内容动态决定下一个Agent客服分流、故障诊断、知识问答高需要可靠的路由策略我个人的建议是能设计成DAG就不要引入环能用静态拓扑解决问题就不要引入动态路由。因为动态路由虽然灵活但它把一部分决策权交给了模型模型一旦选错下游节点整个系统的错误就会沿着图扩散。拿客服系统举例用Pipeline时我们可以严格定义“意图识别 → 信息检索 → 回复生成”三个节点每个节点职责清楚调试时看哪一步出错一目了然。但一旦改成动态路由比如“检索Agent觉得你要投诉就把你转给了售后Agent”这个决策不一定对排查时你还要同时质疑两个Agent的判断。拓扑越简单系统的可预期性越高。2.2 状态与记忆图的灵魂在状态而不是节点很多团队做多Agent系统失败问题不在模型而在状态管理。大家可以想一下单Agent应用里状态就是那一份对话历史。多Agent系统里每个Agent有自己的局部上下文系统有全局的任务状态消息在Agent之间流动这至少是三份状态。如果状态不同步或者同步方式设计得不对系统表现就会非常不稳定。我在实践中推荐的方案是**“共享状态 局部消息”混合模式**。具体说共享状态层放所有Agent都需要访问的全局信息比如任务目标、约束条件、已完成步骤、关键结论局部消息放两个Agent之间传递的过程数据比如代码片段、中间分析结果、附件引用存储介质上共享状态用向量库加图数据库局部消息用消息队列或内存总线这种设计的核心逻辑是给每个Agent“最小必要视野”。共享状态保证所有Agent对任务的认知一致局部消息避免下游Agent被上游Agent每一轮思考过程干扰。聪明做法是让每个Agent只关心自己需要的状态字段。很多失败案例恰恰相反——所有Agent都能读到完整的历史消息导致最后一个Agent的上下文里堆满了前序Agent的废话和幻觉输出质量断崖式下跌。2.3 编排策略谁来决定“下一步做什么”有了图和状态接下来要回答的问题是谁来推进流程目前主流的有三种编排策略我在不同项目里都用过。Planner-Executor模式是最常见的。一个Planner Agent负责把整体任务拆解成子任务图然后Executor Agent逐个执行。适合任务结构清晰、分解方式比较稳定的场景。这个模式的优点是流程可控缺点是你很难让Planner在真正动态的环境里作出合理拆解——比如它不知道某个子任务会失败也就不会提前做备份规划。监督者模式Supervisor是更工程化的一种选择。一个Supervisor Agent管理一组Worker Agent每次由Supervisor决定调哪个Worker、用什么参数、如何评估结果。Claude Agent SDK和LangGraph都支持这种模式。这种模式的好处是决策集中在一点排查问题方便坏处是这个Supervisor Agent本身会成为一个瓶颈和单点。轮询与指引模式在特定场景下也很有用。多个Agent轮流发言、互评比如多角色辩论、设计评审。这种模式对模型质量要求很高因为没有结构化的校验一旦模型层次不够很容易变成“一群人用礼貌的话互相打太极”。我目前最推荐的做法是把Planner-Executor和监督者模式结合起来。第一层用Planner做粗粒度拆解第二层每个子任务内部用Supervisor管理细粒度执行。两层控制的好处是每个决策点的上下文都不会太复杂成功率远高于单层大决策。2.4 可观测性图本身就是最好的调试界面最后聊可观测性。多Agent系统最害怕的是什么是“模型黑盒”加上“流程黑盒”叠加。单Agent出了错至少你还能看它的思考过程。多Agent系统出了错你连错误发生在哪个环节、是哪两方协作出了问题都很难定位。Graph Engineering在这里给了我们一个天然的答案既然系统是一张图那就把图的每一步执行过程都记录下来。我把一个Agent节点的每次执行定义成一条Trace包含以下字段输入消息和来自哪个上游节点该Agent读过的共享状态快照输出消息和传递给哪个下游节点执行耗时和Token消耗状态修改记录一旦有了这些Trace排查问题就变成了“沿着图的边回溯”。前阵子我们定位一个Agent循环执行的问题就是靠画出了实际执行图发现Supervisor在两个Worker之间不断切换每个Worker都给对方的输出打了低分要求重做最终形成了死循环。如果没有图的视角这段代码逻辑你光看日志是完全看不出来的。3. 实操落地主流框架选型与核心配置参考3.1 四个高频框架横向对比理论讲了不少落到实操层面还是要选框架。我把最近一年多社区里最常用的四个多智能体框架做一个横向对比值得说明的是这些框架的底层都或多或少的用到了图结构只是抽象层级不同。框架编排模型开发语言适用场景优势短板LangGraph显式状态图StateGraphPython需要精细控制流程的复杂系统图模型清晰、可观测性好、生态成熟上手门槛偏高状态定义要花时间AutoGen对话式Agent群Python研究原型、辩论式协作灵活度高、支持复杂多Agent对话生产级控制力弱、易失控CrewAI角色协作式Python快速搭建固定流程API简洁、上手快复杂流程控制力弱Claude Agent SDK监督者/子Agent层级TypeScript/Python面向Claude模型的Agent应用与Claude深度结合、开箱即用绑定Claude、定制性受限选型建议很简单如果要做生产级系统最推荐LangGraph。不是因为其它框架差而是LangGraph对“图”的抽象最严格——你的状态、节点、边、路由都是显式声明这正好呼应了文章开头说的Graph Engineering理念。AutoGen更适合研究阶段快速验证协作模式CrewAI适合团队里没有太多工程资源的早期MVPClaude Agent SDK适合你已经明确用Claude做主力模型的场景。3.2 以LangGraph为例的状态图设计与配置我拿一个我们实际做过的“智能开发助手”的例子来说明。这个系统的目标是给定一个需求描述Agent团队要完成代码生成、代码审查、测试方案生成三个步骤。用LangGraph实现时核心代码其实不长from typing import TypedDict, Literal from langgraph.graph import StateGraph, END class AgentState(TypedDict): requirement: str code: str review_comments: list test_scheme: str def generate_code(state: AgentState) - dict: # 调用代码生成Agent code code_generator.generate(state[requirement]) return {code: code} def review_code(state: AgentState) - dict: comments code_reviewer.review(state[code]) return {review_comments: comments} def generate_test_scheme(state: AgentState) - dict: scheme tester.design_test(state[requirement], state[code]) return {test_scheme: scheme} def route_after_review(state: AgentState) - Literal[generate_test_scheme, generate_code]: if has_blocking_issue(state[review_comments]): return generate_code # 有严重问题打回重写 return generate_test_scheme # 没问题进入测试设计 graph StateGraph(AgentState) graph.add_node(generate_code, generate_code) graph.add_node(review_code, review_code) graph.add_node(generate_test_scheme, generate_test_scheme) graph.set_entry_point(generate_code) graph.add_edge(generate_code, review_code) graph.add_conditional_edges( review_code, route_after_review, { generate_code: generate_code, generate_test_scheme: generate_test_scheme, }, ) graph.add_edge(generate_test_scheme, END) app graph.compile()这段代码的核心价值在于route_after_review这个逻辑。审查Agent发现了阻断性问题图就会把流程拨回代码生成节点如果没有问题流程继续前进。这种条件路由在纯对话式多Agent框架里非常难实现而在图框架里只需要一个函数。需要注意的配置点状态类里声明的字段就是各Agent共享的全局状态字段不能随意膨胀控制字段数量是控制上下文污染的第一步节点函数需要设计为纯函数式只依赖传入的state不要在里面做外部IO否则配合多线程执行时会出现状态错乱route_after_review这类路由函数尽量用确定性逻辑判断不要在这里再让模型做决策否则整个图会变得完全不可预测3.3 通信与消息协议让Agent之间说“结构化语言”框架层保证的是图结构但Agent节点之间传什么、用什么传还需要我们设计。很多团队在这个环节吃了大亏他们让Agent之间直接用自然语言互发消息结果每个Agent都要花大量上下文去理解上游的长篇大论而且Agent之间对同一个语义的理解还不一致。解决这个问题最好的办法是为Agent之间的消息定义结构化格式。我在实际项目中是这么设计的{ message_id: msg_20240215_001, from_node: review_code, to_node: generate_code, message_type: review_result, payload: { review_id: rev_088, issues: [ {severity: blocker, file: src/api.py, line: 42, description: 未做输入校验} ], suggestion: 在入口处增加参数校验逻辑 }, created_at: 2024-02-15T10:30:00Z }这样的好处是两个解码成本低——接收方Agent只需要读payload里的JSON字段不需要理解长篇语义可审计性强——每一条消息都能定位来源和去向排查问题时可以精确到某一条消息。消息传输层面我用的是Redis Stream配合本地内存队列。小型系统用Redis Stream足够不需要上Kafka但一定要设置消息过期时间和重试次数防止某个Agent挂掉后消息无限堆积。这里多说一句Agent节点不是纯可靠服务它们调用模型是有概率失败的超时重试和幂等处理必须在一开始就设计好。3.4 记忆与知识注入把GraphRAG落到实处系统智能依赖的不只是Agent之间的协作拓扑还有所有Agent共享的知识底座。我们在项目里把底座的记忆分成了两层第一层是短时工作记忆对应的是前面说的共享状态用Redis或内存数据库存储保存任务进行中的临时结论。第二层是长时领域知识用图数据库加向量检索实现存储的是历史项目的经验、代码规范、常见问题和解决方案。长时知识这一层的具体做法是GraphRAG的简化版。我们先把历史代码库、架构文档、NewBing风格的经验总结切块构建成实体关系图节点保存实体的向量表示。Agent在生成代码或做审查时会根据当前任务的实体类型把相关Node的向量作为上下文注入而不是把所有历史文本一股脑塞进来。这么做带来的提升非常直观代码审查Agent的准确率从大约65%提升到了超过80%主要原因就是它能在审查前找到“过去类似模块踩过的坑”来参照。多智能体系统的知识质量往往比模型本身更能决定系统智能的上限。4. 工程落地中的典型问题与排查实录4.1 节点死锁与无限循环多Agent系统最经典的故障就是死锁。表现为任务卡在一个节点上不推进或者A、B两个Agent无限互打“再审一遍、再改一版”。这个现象在早期项目里太常见了原因通常是条件路由没有兜底分支或者“循环修复”没有设置最大轮次。我们的排查手段有三板斧图结构预检上线前用代码扫描图的边检测是否有多Agent循环依赖的关系加入循环上限每个可能回环的边增加一个max_iterations限制超过就强制终止超时熔断对每个节点的执行设定硬超时比如120秒超时直接标记失败进入兜底逻辑这里我要专门强调一个容易忽略的点多Agent循环在很多框架里是合法的但生产环境必须禁止无界循环。哪怕模型说“我觉得还能再优化一下”只要达到轮次上限就必须输出当前最优解并结束。4.2 上下文污染与角色漂移第二种高频问题是Agent的行为随着流程推进逐渐偏离自己的职责。我们曾遇到过一个测试Agent跑到后面竟然帮代码Agent写起了实现逻辑。后来分析发现它的上下文里被塞进了太多上游Agent的完整推理过程包括代码生成的中间草稿模型看到代码就忍不住开始“改进”。这个问题的根源就是共享了过多上下文。解决方法是“最小可见性”原则每个Agent在声明状态字段时只声明真正需要的字段配置为只读或只写消息传递时只传结构化结果不传上游的思考过程每个Agent系统在休眠时要用提示词约束Agent避免其越界操作我们把这些约束写进LangGraph节点函数装饰器里每个Agent节点只接收白名单字段。实测下来角色漂移的发生率显著降低而且Agent对主任务的完成度有了明显提升。4.3 Agent数量不是越多越好很多团队上来就规划8个、10个Agent觉得这样“覆盖全面”。我的经验恰恰相反Agent数量每增加一个系统的协调成本和故障概率都会翻倍。我们做过对照实验同样一个代码审查任务用1个单Agent是60分用3个Agent协作生成、审查、测试设计可以到88分但当增加到6个Agent时增加了风格审查、安全审查、性能优化整体结果反而降到了80分。原因是多角色Agent之间的建议经常互相冲突最后的集成者Agent不得不在大量对立建议中做取舍。对于多数场景3到4个职责正交的Agent是最优区间。如果你发现任务复杂到需要10个Agent更合理的方案是把任务拆成多个阶段每个阶段用一个3Agent小组而不是一次性把所有角色堆在一起。Agent数量适用场景效果表现1简单任务、单角色60-70分稳定但上限低3-4中等复杂任务、多角色分歧85-90分最佳性价比6任务过大、角色重叠反而可能下降协调成本高4.4 成本与延迟失控最后一个避不开的问题是钱。多Agent系统的Token消耗是单Agent的数倍到数十倍如果用高配模型一个稍复杂的流程跑下来token成本可能让决策的老板当场脸色变青。控制成本和延迟的经验非核心节点用轻量模型。比如信息检索、格式整理、简单分类的Agent完全可以用7B级别的开源模型或高速低成本模型只有核心决策节点用旗舰模型并行化执行。把相互独立的Agent节点放到不同执行线程/进程中并行跑整体耗时从串行求和降到最大单点耗时结果缓存。对于重复性检索和固定格式的中间结果在Redis里做缓存避免每次任务都重复计算主动终止。当所有必要的Agent已经达成一致结论时提前终止后续节点不要“为了流程完整而跑完整”5. 多智能体时代的工程规范与治理思路5.1 Agent代码开发协作从“玩具”到“团队契约”热搜词里有个“clawswarm多智能体 ai 协作框架”和“多智能体 ai agent coding协助开发规范”我理解这正是很多人头疼的领域到底怎么让多个Agent真的像成熟工程师团队一样协作写代码我们团队内部已经形成了一套Agent开发协作契约写在这里供大家参考。这个契约和人类团队协作几乎是同构的角色边界只能有一个“指挥官Agent”负责拆解任务和验收结果多个“开发者Agent”按模块并行编码一个“审查者Agent”负责代码质量把关交付物格式开发者Agent必须输出“代码变更说明自测结果”三件套缺少任意一项视为交付失败验收标准审查者Agent的拦截规则中安全漏洞、明显的逻辑错误是阻断项代码风格问题是建议项阻断项不解决不许合入变更记录所有Agent的代码变更必须关联到图上的任务节点ID方便回溯哪个决策对应哪段代码这套规范最核心的一点是角色边界和裁决规则写得非常死板——不依赖Agent“自觉”而是由工程实现强制保证。比如“开发者Agent的输出不改动审查者Agent对应代码模块”这个用权限体系直接切断模型想越权都没办法。只有这样的治理机制存在Agent才会表现优秀。5.2 权限最小化与安全边界多Agent系统的安全模型和单Agent不同单Agent的权限是全无或全有多Agent可以也必须在节点级别配置细粒度权限。我们在生产环境里做了这么几件事每个Agent节点绑定独立的服务账号只授予该节点职责所需的API权限不授予完整仓库权限所有Agent执行外部命令、修改文件、调用生产接口的行为统一走沙箱网关超时和输出大小都有限制涉敏操作部署、数据删除、高价接口调用默认“阻断”必须由人工审批后才能继续执行这里要特别提一个容易被忽视的安全点Agent之间的消息通信也可能携带敏感语义。比如开发者Agent把数据库密码写在代码里这个代码片段会作为消息传给审查Agent再传给日志系统。我建议在消息通道上做独立的敏感信息脱敏处理效果显著。多智能体系统的攻击面是面上展开的任何两个节点间都可能出问题治理要求必须比单Agent更严。5.3 让图工程成为团队语言最后说说团队协作层面。我们团队讨论Agent系统时现在统一用图和关键词来沟通。开会时说“这个流程这里有个回环”大家立即懂是什么意思不会再像早期那样争论“是Supervisor的问题还是Worker的问题”。我会把每一版Agent拓扑图纳入版本管理通过git管理配置图中的每个节点、每条边、每个状态字段的改动都必须过review。这种做法的好处在项目交接和新人入职时尤其明显。新人不需要读一坨代码只要看拓扑图和状态定义就能理解系统全貌和潜在风险。多智能体系统慢慢会像分布式系统那样形成一套自己的设计规范和运维流程图就是这套规范的最底层载体。从个体智能到系统智能这条路没有捷径。唯一的通路是把Agent当作可治理的系统组件用图去定义它们的连接、状态和协作契约再用工程手段确保这一切稳定运行。我始终觉得未来能拉开差距的团队不是比谁的模型调得好而是比谁先把Agent协作的“水电煤”基建搭扎实。在过去几个项目里我习惯性地会在写多Agent代码前先画一版设计图哪怕手画也行。落地的这个习惯帮我避开了很多坑因为画图的过程会强迫你理顺节点职责、边上的数据流回环、状态字段的归属。对Graph Engineering还没太多体感的读者我建议从这一步开始。这方法朴素但管用值得一试。