graph engineering（图工程），就是把一个复杂任务，从"交给一个智能体从头干到尾"，改成"拆给多个各有专长的智能体，再用一张图把他们连起来协同"。 图里的节点是一个个干活的智能体，边是他们之间怎么交接，中间还有一份共享状态一路流动。2026 年 7 月中旬开始在 X 上被叫响，而支撑这个名词的，是一批早就跑通的工程做法。
凡是认真用过智能体的人，几乎都撞过同一堵墙。你派给它一个不算简单的活儿——查一堆资料、写成报告、再挑刺审一遍、最后决定发还是打回——它一开始干得挺好，可越往后越像一个连轴转了十几个小时的人：前面查的资料忘了一半，写着写着跑了题，自己审自己的稿子还总觉得哪儿都好。问题很少出在它不够聪明，多半是这活儿压根就不该让一个智能体从头扛到尾。图工程给的正是这堵墙的解法——该拆的拆开，该并行的并行，该复核的另派一个专门的去查。
今天我们就来说清楚三件事：图工程到底是什么、为什么会在此刻冒出来，以及两个你可能在用的 AI 工具Claude Code 的 dynamic workflow 和 Codex 的 multi-agent——是怎么把这套思路落到实处的。
先把"图"这个字讲明白
图工程听着玄乎，拆开看其实只有三样东西。
第一样是节点（node）。每个节点就是一个干具体活儿的单元，通常是一个有专门职责的智能体——一个"研究员"、一个"写手"、一个"审稿人"——也可以是一段老老实实的确定性代码，比如一次函数调用、一次工具请求、一次数据读取。关键在于，每个节点只干一件事。
第二样是边（edge），也就是节点之间怎么走。边可以是直的，A 干完交给 B；可以是有条件的，审稿通过就发布、不通过就退回去重写；可以是一分多，一个节点同时点燃三个节点并行去跑；也可以是多合一，三份结果汇回到一处。
第三样是共享状态（shared state），它是那个顺着边一路流动的对象，装着任务本身、目前写到哪儿了、有哪些笔记、审出了什么结论。每个节点都从它这里读，也往它这里写。有了这份共享记录，一堆各干各的智能体才算真正连成了一个系统，而不是一个转头就忘的临时群聊。
图工程就是给智能体画组织架构图。一家公司不会让同一个人把调研、写作、审核一口气全包了，而是拆成不同岗位，让活儿在岗位之间流转，结果层层汇总上来。智能体的图，走的是同一个道理——专门的角色，说好的交接，一份共享的档案。
下面这张是最经典的入门图：研究员把笔记喂给写手，写手交给审稿人，审稿人这里挂了一条有条件的边，决定是发布还是退回。你可以顺着箭头看状态是怎么一路长大的。
三个节点，几条边，其中一条是有条件的判断，一条是绕回写手的回环。状态一路往下流，越流越厚：研究员的笔记跟着到了写手手上，写手的初稿又跟着到了审稿人那里，审稿人的结论决定接下来走哪条边。
有意思的是，这套东西并没有把过去的经验推翻。一个单独在打转的智能体，本质就是一张只有一个节点、还带着一条指回自己的边的图。你之前学的那些"感知—规划—执行—检验"的循环、什么时候该停、由谁来把关，全都还在，只是它们变成了单个节点内部的事。图工程管的，是当你手里有好几个这样的循环、彼此需要交接时，它们该怎么连起来。
为什么偏偏是现在，长成了这个样子
要理解图工程为什么会冒出来，得把这两年 AI 工程的重心挪动看成一条线。
最早大家拼的是 prompt（提示词），琢磨怎么把一句话问好。后来发现光问得好不够，得管好模型看到什么，于是有了 context（上下文）这一层。再往后，重心挪到了 harness（脚手架）——给模型配上工具、记忆和各种外围支撑。到了 2026 年初，大家开始认真设计单个智能体的循环（loop）：让它自己规划、动手、检验、返工。而到了 7 月，重心又往外挪了一格，落到了多个智能体之间怎么协调上，这就是图。
看这张表你会发现一个规律：每往外挪一层，你操心的东西就离模型本身更远一点，而你手里的杠杆更大一点。图工程之所以长成现在这个样子，核心就一句话——当一件活儿从"一件事"变成了"好几件需要交接的事"，你还硬把它塞进一个循环里，就是用错了容器。
Loop Engineering 循环工程
harness 怎么训练 harness
这里得说句公道话。图这个东西一点都不新。有人直接开怼："恭喜你，重新发明了 LangGraph。"这话基本没错。用节点、边和共享状态来搭智能体系统，LangGraph、微软的 AutoGen、谷歌的 ADK 早在这个词流行之前就做了，往上追甚至能追到几十年前的数据流架构、状态机和多智能体研究。所以真正在 7 月发生的，谈不上什么新能力，更像是一次命名事件：一个憋了很久的设计问题，终于有了一个能拿出来讨论的名字。名字本身可有可无，但那个从"一个循环"一步步走向"一张协调好的图"的过程，是真实存在的。
主流 Agent 框架详解与对比：技术深度分析与实战指南
Multi-agent 为什么绕不开图工程
聊到多智能体，很多人第一反应是："不就是多开几个智能体一起干嘛，有啥好讲的。"真上手你就知道，多开几个和让它们协调好，中间隔着的正是图工程。原因有这么几条，每一条都很实在。
第一条，上下文会被撑爆 单个智能体扛复杂任务，问题很少出在它不够聪明，多半是一个上下文窗口装不下这么多东西。查来的资料、中间的草稿、来回的讨论全堆在一处，模型的注意力被稀释，越到后面越糊涂。拆成图之后，每个节点都有自己干净的上下文，研究员只管研究，写手只管写，互不污染。
第二条，该并行的活儿不该排队干 很多任务里有大段彼此独立的工作，一个智能体只能一件件按顺序来，可换成图，你就能让一个节点一分多，同时点燃几个子任务并行去跑，再在某个节点汇合。这不光快，有时候是唯一算得过账的做法。下面这张"一分多、再合一"的图，是多智能体里最常见的形状：
第三条，不同的活儿想用不同的家伙什 调研也许需要联网搜索，写作要换一套语气，审核最好用一个只读、还是另一个模型的智能体来干——单个循环很难在中途切换模型和工具集，图天然支持每个节点配自己的那一套。
第四条，也是我觉得最容易被低估的一条：审核这件事，最好交给别人 在单个循环里，是智能体自己检查自己的输出，这就像让写稿的人自己当审稿人，多半会觉得处处都好。图工程里可以专门立一个审稿节点，用一个独立的、只读的智能体去挑另一个节点的毛病。这一条几乎是整张图里价值最高的设计。
第五条，出了错能兜得住 在一个循环里，一步走岔可能把整段上下文都带偏。而在图里，你可以做到一个节点失败了就地重试、或者转到备用节点、或者升级给人来看，而不至于污染下游、连累全局。
多智能体真正难的地方，从来都不在多开几个，而在于谁负责什么、谁能和谁说话、活儿按什么顺序流、大家共享哪一份状态。这些恰恰就是图工程要回答的问题。
Claude Code 的 dynamic workflow：让智能体自己写包工头
Claude Code 在 Opus 4.8 一起推出的 dynamic workflow（动态工作流）。
它的设计有一个很聪明的地方。平时你用 Claude Code，Claude 自己就是那个"包工头"（orchestrator），一步步决定下一个该派谁、干什么，而每一步的中间结果都堆回它自己的对话里。任务一大，这个对话就被各种中间产物塞满了。dynamic workflow 换了个思路：让 Claude 先写一段 JavaScript 脚本，由这段脚本来当包工头。循环、分支、中间变量全都装在脚本里，Claude 自己的上下文最后只留一个干净的结论。
这段脚本靠几个很小的原语来指挥智能体，理解了它们，你基本就懂了这套东西：
agent(prompt, opts) 派出一个子智能体去干一件事。它有自己独立、干净的上下文，干完只把最终结果交回来——如果你给了 schema，交回来的还是一个校验过结构的对象，下游可以直接放心地取字段用。这就是那个"一个智能体、一个干净上下文、一个目标"的最小工作单元。
parallel(thunks) 一次点燃一批任务，然后等它们全部干完再往下走。这个"等"是它的灵魂——它是一道栅栏。只有当下一步确实需要拿到前面所有结果时（比如要在整批里去重、或者互相比对），你才用它。
pipeline(items, ...stages) 让每个条目独立地穿过每一道工序，中间不设栅栏。A 条目可以已经跑到第三道工序了，B 条目还卡在第一道。大多数多阶段的活儿其实不需要互相等，所以这才是更常用的默认选择。
phase(title) 把一组智能体归到一起，方便你在界面里盯进度。
这里还藏着一个容易被忽略、但特别关键的设计约束：脚本必须是确定性的，里头不能有 Date.now()、Math.random() 这种每次都变的东西。为什么？因为这套运行时支持"断点续跑"——一个跑了一半被打断的工作流，重启时会从头把脚本重放一遍，已经跑完的 agent() 调用直接复用缓存好的结果。要是脚本里有随机项，重放时分支就走岔了，缓存的结果和新的执行路径对不上。是确定性，让续跑变得安全。这是很典型的图工程思维：不光设计正常怎么跑，还得设计断了之后怎么接。
对着前面那三样东西看：agent 就是节点，parallel/pipeline 就是边（栅栏式的合流、流水线式的并行），脚本里传来传去的那些变量和 schema 就是共享状态。名字换了，骨架是一模一样的。
Claude 官方还总结了几种常用套路，最典型的两个：一个是分治再汇总——把大任务切成一堆小步，每步派一个智能体、各用一块干净上下文去跑，最后设一道栅栏把结构化结果合并；另一个是竞标——同一个活儿派 N 个智能体用不同思路各做一版，再让一个裁判智能体两两比、评出个赢家。
这套东西能铺多大？官方给的数字是，单次 run 最多能并发 16 个智能体、累计最多 1000 个。Anthropic 自己就拿它来跑 /deep-research、做大规模代码迁移、审计整个代码库；连 Claude 的安全插件做多智能体漏洞扫描，底下撑着的也是这套 workflow。这些活儿的共同点很清楚——阶段多、要交叉验证、还得能复跑，恰好是脚本化编排最擅长的地方。
Codex 的 multi-agent：一棵会自己长出来的智能体树
再看 OpenAI Codex 这边。它的路子和 Claude Code 有点不一样，更偏向"由模型自己在运行时开枝散叶"。
Codex 里有一个"父"会话，它可以按需生出一批专门的"子智能体"，让它们并行去干，等结果回来，再综合成一个最终答复。整个协调过程主要靠这么几个动作：spawn_agent 开一个新的子智能体去接一个具体任务；send_message 往某个智能体那儿塞条消息，但不触发它开跑；followup_task 是塞消息并且让它开跑；wait_agent 让父会话停下来，等子智能体们都跑到终态；还有 list_agents 用来看看这棵树上现在都有谁在跑。
和 Claude Code 那种预先写好一整段脚本不同，Codex 的这些动作是模型一边想一边发出来的，它们以工具调用的形式出现在父智能体的推理链里。换句话说，你是用提示词去引导它，而不是自己写代码去接线。你直接说一句"给每个评审点各开一个智能体，全部等齐了再逐个总结"，Codex 就会一个点开一个线程，最后合并给你。
到 2026 年年中，Codex 的这套东西分成了两层。MultiAgentV1 偏手动，靠开发者在 TOML 配置里声明好每个智能体的角色、用哪个模型、花多大推理力度，指令都是明文存着的。MultiAgentV2 则更自动，由运行时自己去分配调度，也是 GPT-5.6-Sol、Terra 这些新模型的默认选择；它的委派消息在 OpenAI 的基础设施上是加密的，所以在本地的审计日志里看不到具体指令内容。
Codex 还给这套东西上了几道很实在的"限速"，这恰恰是图工程里成本控制的体现。并发数默认被 agents.max_threads（默认 6）卡住，嵌套深度被 agents.max_depth（默认 1）卡住。官方特意提醒：把嵌套深度往上调很诱人、但很危险，因为一句宽泛的委派可能层层裂变成反复的一分多，token 消耗、延迟和本地资源占用都会跟着往上窜。它还有个 spawn_agents_on_csv 的批处理工具，能把一个 CSV 文件里每一行都扇出给一池并行的工人智能体去处理，各自把结果写回。
实际用起来，Codex 的多智能体主要招呼那些能拆开、又能并行的活儿：探索一个陌生代码库、审一个 PR、并行开发几个特性，或者挂在后台跑长任务。在桌面应用里，这些并行工作被拆进各自的 project、thread 和 worktree（一份份独立的工作副本），几个智能体同时改一个仓库也不至于打架。
说到底，Codex 干的也是同一件事：父智能体是包工头，spawn_agent 生出节点，wait_agent 是那道合流的栅栏，子智能体各自干净的上下文加上综合汇总，就是共享状态的流转。它和 Claude Code 的区别，主要在于图是预先写死在脚本里，还是由模型在运行时边想边长出来。
agentparallel/pipeline/phase | spawn_agentwait_agent/send_message/followup_task | |
市面上其实有两个"图工程"
这里得提醒一句，免得你回头去搜的时候被绕晕。Graph engineering 这个词今天挂着两层意思，指的是两拨人干的两件不太一样的事。
一层是数据意义上的图，把现实世界里的实体和它们之间的关系，直接建成"节点—边—属性"的结构来存、来查、来算。知识图谱、图数据库（比如 Neo4j 那套用 Cypher 查询的属性图，或者 W3C 那套 RDF 三元组）、图算法，乃至在图上做学习的图神经网络（GNN），都归在这一层。它回答的是"这个系统知道些什么、这些东西之间怎么牵连"。
另一层，就是这篇文章一直在讲的执行意义上的图——把智能体、工具、状态、审批、消息流显式地摆成一张能跑的图。它回答的是"这个系统由谁组成、活儿怎么在他们之间流动"。
一个好记的说法：数据图管的是系统知道什么，执行图管的是"系统是谁"。两者能在同一个架构里并存，各答各的问题。这篇文章的主线是后一个，但下面这些真实落地的例子会让你看到，前一个早就在闷声干大事了。
跳出智能体圈：图工程早就在挣钱
智能体编排是图工程最新、最热闹的用法，可"拿图来解决问题"这件事，在别的领域已经安安静静赚了很多年钱。它们背后其实是同一句话：有些难题的本质是"关系密集型推理"——谁和谁有牵连、钱从哪儿流到哪儿、这条依赖链动一处就牵全身。这类问题，用图来表达，比拆成一张张表再回头拼关系要近得多。 Neo4j 讲反欺诈时打过一个比方：识别一个欺诈团伙，说到底就是"在图上走一圈"。
几个真实的例子，数字都挺能说明问题。
搜索和企业知识问答这块，微软的 GraphRAG 先让大模型把资料自动抽成一张知识图，再靠社区发现和分层摘要，去回答那种"得通览全局才答得上来"的复杂问题，这恰恰是普通向量检索很难啃下的。
推荐这块，Pinterest 的 Pixie 系统跑在一张 30 亿节点、170 亿条边的对象图上做实时推荐，论文里报告相比旧系统最高带来 50% 的互动提升，单机延迟压到 60 毫秒级。
金融风控这块，法国巴黎银行旗下的消费金融公司公开过一个案例：用 Neo4j 的图做反欺诈，把欺诈降了两成，最大延迟约 2 秒。
生物医药这块，DGL 团队放出过一个叫 DRKG 的生物知识图，把基因、药物、疾病、副作用连成了 9 万多个实体、580 多万条关系，专门用来做"老药新用"的药物重定位。
还有软件供应链，GitHub 的依赖图（dependency graph）和 CodeQL，本质上就是把代码之间的依赖关系、程序语义和数据流显式建成图，再拿去定位漏洞、治理供应链风险。
图工程真正的底色是 把"关系"这件事，从藏在数据缝里的隐性信息，变成可存、可查、可算、可追溯的一等公民。 智能体编排，只是这条老路上最新长出来的一段。
两个"图"怎么合体：知识图给多智能体当共享大脑
前面聊多智能体时说，它的第一个坎是上下文被撑爆。这里正好接上——这个坎有一个挺漂亮的结构性解法，来自 Anthropic 的一份知识图工程 Playbook，而它恰好就是前面那两个"图"合体的地方：拿一张数据意义上的知识图，去给一套执行意义上的多智能体当地基。
先把这个坎说透。多智能体最根本的软肋，是每个智能体的记忆，都随着它那个上下文窗口一起消失。拿一个做竞品分析的系统来说：五个 worker 各看一摊资料，定价、产品、财务、市场各管一块，最后得有一个"综合"的智能体，把跨来源的线索串成一句话——"那家降价 15% 的公司，正是专利显示要开新品线、财报显示研发翻倍的同一家"。可这三条事实，没有任何一个 worker 同时看到过。要是大家都靠主控（orchestrator）的上下文转发摘要，那个窗口会随 worker 数量线性膨胀，迟早超过再大的模型也装不下的极限。
解法是给这套系统垫一层共享的知识图：每个 worker 把自己的发现写成"实体 + 关系"存进图里，那个综合的智能体不去重读原文，只在图上遍历，就能把散落各处的线索连起来，中间那些庞杂的上下文一概不用背。
在多智能体里，这张图能扮演三个角色，个个关键。一是共享记忆：worker 们共同读写同一张图，替掉那种靠主控转发摘要、又脆又堵的老办法。二是事实校验的依据：跑生成—评审这类循环时，评审的智能体可以拿生成方的每一句话去图上对边、查出处，把判断从"看着像不像对"升级成"到底是不是真的"。三是跨会话的持久世界模型：一个挂着跑通宵的循环，上下文一遍遍被清空，可图还在——用那份资料里的话说，智能体会忘，图不会。
建这张图的成本，这几年也掉得很厉害。过去要建知识图，得先训一个命名实体识别模型、再训一个关系分类模型、还要手写一堆实体消歧规则，换个领域就得从头再来。现在这一整条经典流水线，被 Claude 拆成了几段带结构化输出的提示词：抽取（用便宜的 Haiku 跑量）、消歧（用更会推理的 Sonnet 做判断）、组装、查询。真正意义上的"训练数据"，就剩一个描述数据长什么样的 schema。
顺带回答一个常被问到的问题：知识图和 RAG（向量检索）到底什么关系？简单说，RAG 擅长"答案就摆在某一段文字里"的单跳问题；可一旦答案得靠串联好几篇彼此毫不相似的文档才能拼出来（多跳），RAG 就接不住了，而图里那个把两篇文档连起来的实体节点，恰好能顺着边走通。两者是互补的：RAG 负责快检索，知识图负责结构化的推理。
最实在的好处在最后：图上答出来的每一句，都能指回具体的那条边、那份来源文档。在你自己的私有资料上，这种带出处、可追溯的答案才真正靠得住。也难怪 Anthropic 自己的数据说，在那种需要同时铺开好几个方向的任务上，多智能体能比单智能体强出九成，代价是要多烧十几倍的 token——而知识图，正是给这份高昂的上下文开销准备的一套结构化解法。你的智能体为什么总是忘记你说过的话
智能体开始进入「复盘 — 评测 — 改进」的循环
优势与劣势，都摆到台面上
先说图工程好在哪。它把过去藏在提示词里、靠模型自由发挥的那些路径，变成了明明白白、可以审计的结构。你能画出来、能静态地推敲、能一个节点一个节点地去看谁花了多少钱、跑了多久、用了哪个模型。它让专精成为可能——每个节点用最合适的模型和工具。它让并行成为可能——该同时干的活儿不必排队。它还让把关变得独立——审稿的和写稿的不再是同一个。对那些跨领域、要并行、还会随时变形的活儿，这套结构是实打实的解药。
但劣势同样得说清楚，而且这一点比优势更重要。绝大多数任务，压根用不着图。
X 上对这个词的嘲讽来得几乎比这个词本身还快，而且开炮的都是懂行的人——有 XState 状态机工具的作者，有做多智能体协议 A2A 的人。他们的意思很一致：有向图、状态机这些东西是几十年的老计算机科学了，把它当成七月的新发现来吹，多少有点营销的味道。这些话该听进去。
Agent2Agent 协议：AI 智能体协作的未来
更实在的风险是过度设计。举个例子，"帮我把这份 PDF 总结一下"，你却给它搭了个五节点的图：一个抓取、一个切块、一个总结、一个审核、一个排版，还配上有条件的边和共享状态对象。它确实能跑，可它比那件本该做的事——一个智能体读完文件、写个总结——搭起来更慢、更难调、跑起来更贵。你为了回一封邮件，硬生生画了一张组织架构图。
还有几个坑也值得记住：图是很多个循环的叠加，一个不靠谱的审核节点会在并行里成倍地烧 token，所以成本必须显式地设上限；共享状态如果没规定好谁能写，很容易慢慢"漂移"到一团乱；而如果你的每个节点本身就是个弱智能体，把它们连成组织架构，得到的也只是一个弱组织。下面一层没打牢，上面这层图只会以一种更花哨的方式失败。
往数据图那一侧看，账也不轻松：建模门槛不低，属性图和 RDF 是两套不同的生态、Cypher 和 SPARQL 是两种查询语言，工具链天生就碎；更要紧的是，图里的"关系结构"本身就是敏感信息——谁能遍历哪些边、看到哪些属性，都得有细粒度的权限管着。Neo4j 官方专门强调过这点：节点、关系和可遍历的路径，都需要单独的访问控制。智能体这边同理，运行时留下的 trace 里往往带着大量业务上下文，也该按最小权限和脱敏来管。
Token 这门生意，账单最后寄给了谁？
所以判断要不要上图，有个特别朴素的检验：你要搭的这张图，是不是在干一件循环干不了的事？如果你能把五个节点重新塌回成一个智能体的循环、还啥都不少，那你就该塌回去。
什么时候，才真该请出图工程
综合下来，判断标准可以压成几个信号。当活儿明显裂成了几个会互相交接的专业分工、当你需要一分多地并行再合流、当不同步骤要用不同的模型或工具、当你需要明确可审计的路由而不是让智能体自由乱走、当你希望一个节点崩了不连累其他、当你需要一个专职的审稿人去查另一个节点的活儿——这几条里要是大部分都戳中了，图才真正值回它的复杂度。
反过来，一个范围清楚、有明确验收标准的单一任务，它就是一个循环，在这儿上图纯属给自己添乱。还有一种情况也别硬上：要是几个智能体必须频繁地改同一份共享状态、你争我抢，那强顺序的单代理、甚至一个老老实实的状态机，往往比图化编排更稳。OpenAI 官方也提醒过，多智能体擅长的是独立、有边界的任务，最怕的就是大家一起反复写同一块可变状态。
一个能落地的顺序是这样的：先想尽办法把它保持成一个循环，一个智能体配一个好的验收标准，能搞定就到此为止；实在裁不动了，再给真正的专业分工各起一个节点；动手写代码之前，先把边画在纸上，顺序的、并行的、汇合的、那条唯一的回环边，一张餐巾纸画不下就说明太复杂了；然后把共享状态设计清楚，规定好谁能写；给审稿节点配上真牙齿，让它独立、只读；再确保单个节点能失败重试而不污染全局；最后，能用现成框架就别自己造运行时，该设的成本上限一个都别省。
如果你要搭的是个正经的生产系统，还有个分层的思路值得记在心里：把知识图（实体和关系）、执行图（智能体、任务、依赖）、观测图（trace、成本、审批、失败）三样东西分开来放。分开的好处，一是权限好隔离，二是日后优化和审计都有地方下手——哪个节点贵了给它换个便宜模型，哪条子任务老翻车就单独盯着，一目了然。
顺着往下看，会走到哪儿
图里的节点，正在悄悄升级。早两年，一个节点里装的多半是一段确定性代码，或者一次模型调用；而现在，一个节点里越来越常装的，是一整个能自己规划、动手、检验的子智能体。用 LangChain 官方的说法，今天图里的一个 node，完全可以就是一次完整的 agent run。
配套的两个苗头也已经能看见。一个是分工上的精打细算：让强模型专门做规划，把便宜的小模型派去做探索和打杂的子智能体，Codex 和 Claude 都已经支持把子智能体路由到更省钱的模型。另一个是把观测、护栏、人工审批这些原本的附加功能，直接做成图里的节点和边——该审批的地方就摆一道审批节点，让约束长在结构里，而不是飘在提示词里。
回到开头那个连轴转、忙不过来的智能体。
它给我们上的那一课，其实和管理团队是相通的：一个人再能干，也扛不下一整个需要分工协作的项目；真正的本事，是把活儿拆成清楚的角色，安排好谁先谁后、谁把关、大家共享哪一份信息。图工程说到底，就是把这套朴素的管理常识，翻译成了智能体能执行的结构。
Claude Code 让智能体自己现写一段脚本来当包工头，Codex 让父会话在运行时自己长出一棵智能体树，路子不同，骨架一致——都是节点、边和共享状态。名字新不新、火不火，其实没那么要紧。要紧的是，当你下次又看着一个智能体在复杂任务里越绕越晕时，你能认出来：这不是它不够聪明，是这活儿该拆了。
而拆得好不好，考验的从来都不是你会不会写花哨的提示词，是你有没有想清楚——这件事，到底该由谁、按什么顺序、共享着什么，一起把它干完。
