第 10 章搭一个能替你干活的 Agent

上一章结尾，我们停在一个门槛上：七个问题只回答了「该不该做」，被它们筛过、确认值得做的那一个，接下来该真的造出来了。到这里，全书也走进了第三部「造物」。前九章你练的都是「一个人把 AI 用扎实」——写指令、给记忆、封装成 Skill、织进工作流，最后练判断；从这一章起，目标变了：不再只是自己用得顺手，而是做出一个你不在场时也能自己干活的东西。这是第三部的第一章，也是从「用 AI」跨到「造 AI」的第一步。

我先抛出这一章的核心判断，然后用一整章去论证它：一个 Agent 能干多大的活，不取决于架构图上有几个圆圈，取决于你把第一个圆圈教到了什么程度。用一句更好记的话说——搭 Agent 跟招人一样，先把一个人带明白，再考虑给他配团队。这一章从头到尾，讲的都是这次「招聘」：怎么写他的岗位说明书，怎么做交接，什么时候才轮得到扩编。

先看一个具体的人。小雯是一家出海 SaaS 公司的产品经理。每周一早上九点半，公司开竞品例会，会上那份竞品动态简报，由她负责。

为了这份简报，她的周日晚上是这么过的：打开六家竞品的官网，挨个翻 changelog，看上周发了什么功能；点进定价页，对着上周存的截图比对，看有没有偷偷改价；再刷一遍这六家的官方博客和 X 账号，把营销动作记下来；最后去 G2 翻新增的用户评论，看有没有人在骂或者在夸。信息凑齐，她再花一个小时把几十条原始动态压成一页纸：本周谁动了什么，对我们意味着什么，建议关注哪几条。

让我们算一笔账。整个流程，三个小时；一周一次，一年五十来周，就是一百五十多个小时的周日夜晚——她已经这么交了一年多。最气人的是，这三个小时里没有一分钟需要她的专业判断：信息源是固定的，比对方法是固定的，连简报的格式都是固定的，她只是一台会喊累的爬虫。真正需要她的，只有最后那一个小时里的几个判断：这条动态重不重要，对我们意味着什么。前两个小时，纯粹是搬运。

促使她动手改变的，是上一章讲过的那套判断。她把这件事放在七个问题下面过了一遍：痛点真不真？真，一年一百五十个小时，全是她自己的命。流程清不清楚？清楚，信息源固定，判断标准她闭着眼都能背出来。错了有没有兜底？有，简报发出去之前她自己会核一遍，错一条丢不了客户、上不了热搜。ROI 算不算得过来？她周日晚上的时薪，怎么算都比一个 AI 贵。

这是一个值得做的真问题。判断完了，下一步就是动手。

她的第一反应，是去网上找别人的方案。搜出来的第一张架构图就把她镇住了：七个圆圈，研究员 Agent、分析师 Agent、撰稿人 Agent、审核 Agent，箭头连成一张网，配文写着「我的 AI 竞品分析团队」。评论区一片喊「牛」的，还有人贴出自己的版本，九个圆圈。她截了图，心想原来要搭七个，自己连一个都还没有。

这一章想劝住的，就是这个瞬间。先别管那七个圆圈。我们从一个搭起。

一、从流水线到自己拿主意

动手之前，先把一个概念掰清楚：你要搭的 Agent（智能体），跟第 8 章的工作流，差在哪？

工作流是你把路线画死，它照着跑。表单进来、AI 打标、按标签路由，每一步走哪条路，是你提前规定好的。它像一条流水线，稳定、可控，但遇到没画过的路口就会停。

Agent 不一样。你给它的是目标和边界，路线它自己定。第 8 章说过那个心态转变，Think like a manager——给 AI 目标和限制，让它自己决定怎么完成。工作流里这句话只兑现了一半，因为每个节点之间的路径还是你画的；到了 Agent 这里，这句话才算当了真：你说清楚要什么、不许什么，中间怎么走，它自己看着办。

为什么小雯的场景非升级不可？因为竞品监测这件事，恰好卡在流水线管不住的地方：六家竞品里有一家这周把博客改版了，旧的抓取路径失效，它得自己想办法找到新入口；G2 上一条评论提到了一个你们没听过的新对手，要不要顺藤摸瓜去查一眼，得它自己判断；某家的 changelog 这周发了十一条更新，哪几条值得进简报，没有规则能提前写死。路线每周都在变，判断没法提前穷举；这种活，流水线接不住，得交给一个能自己拿主意的东西。

那这个东西由什么构成？拆开看，就三样：决策、工具、记忆。

三样不是并列关系，而是分了层的：决策是它脑子里那套「遇到情况怎么办」的章法，定它怎么想；工具是它伸出去碰真实世界的手脚，定它够得着什么；记忆是它对你、对这件事来龙去脉的掌握，定它跟你共事得久不久。三样齐了，它才配叫 Agent。少了决策，它是一条死板的流水线；少了工具，它是一个只会出主意的军师，说得头头是道，一件事也办不成；少了记忆，它是个每周一失忆的临时工，你得从头交代一遍。

市面上很多自称 Agent 的东西，拿这三样一照就现了原形：有的只是套了壳的对话框，三样全无；有的把固定流程包装成「智能体」，其实路线一步没让 AI 做过主。你以后评估别人的产品，或者检查自己搭的东西，都可以先问这三样齐不齐。

好消息是，这三样里有两样，你已经在前面的章节里打过地基了。

二、岗位说明书、交接文档与一张工卡

回到招人这个比喻。一个新员工入职，你要给他备齐三样东西：一份岗位说明书，一套交接文档，一张工卡。恰好对应决策、记忆、工具。

岗位说明书，就是 Prompt。第 5 章你已经学会写它：角色定义、任务说明、输入约束、输出要求。在 Agent 这里，它要再升一级——从「一次任务的说明」升级成「一个岗位的职责与边界」。区别在哪？给对话框写 Prompt，你描述的是这一次要它干什么，写坏了大不了重发一条；给 Agent 写 Prompt，你描述的是这个岗位长期对什么负责、什么坚决不准碰、拿不准的时候怎么办，因为它会在你不在场的时候，按这份说明书自作主张。也因为它要长期服役，第 5 章那三根支柱在这里从「建议」变成了「必须」：版本化管理，留一套测试集，每次改完重跑一遍。对话框里的 Prompt 翻车，丢的是五分钟；Agent 的岗位说明书翻车，它会用同一个姿势，安静地错上一整个月。

小雯给她的竞品监测 Agent 写的岗位说明书里，有这么几条：你只报告有信源的事实，每条动态必须带原文链接；你可以判断一条动态重不重要，但必须给出理由；遇到付费墙后面看不到的内容，标注「未能核实」，不许猜。最后一条最重要，第 2 章主厨们就该懂的规矩：没把握的时候停下来问，而不是硬着头皮蒙一个。

交接文档，就是记忆，第 6 章的 Context Management。一个合格的竞品监测 Agent 得记住三类东西：一是长期的档案，六家竞品的名单、各自的信息源、历史动态的存档，这是它的档案记忆（Archival Memory）；二是本周的工作台，这一轮抓到的几十条原始动态，这是它的工作记忆（Working Memory）；三是你调教过的判断，比如小雯纠正过一次「这家的官方博客全是软文，降权处理」，这句话必须被记下来，下周还能生效。三类记忆缺哪类，病症都不一样：缺档案，它认不出「这条上周报过了」，简报里全是回锅肉；缺工作台，它分析到第四家时已经忘了第一家说过什么；缺调教记录，你纠正过的错它下周原样再犯，你的耐心会在第三个周一耗尽。记不住这些，它每周一都是新来的，你等于每周重新培训一个实习生。

第三样是新零件：工卡，也就是工具（Tools）。前两样给了它脑子和记性，工具给它手脚——让它能真的去打开网页、读 RSS、查数据、把结果写成文档发给你。技术上，这就是让 Agent 调用外部 API 的能力：你授权它访问哪些信息源、能动用哪些动作，它就在这个范围里自己组合着用。这也是 Agent 跟聊天机器人最硬的一条分界线。聊天机器人的输出是一段话，落不落地全看你；Agent 的输出是一件办完的事，因为它的手伸得到事情发生的地方。小雯的第一版很克制，工卡上只开通了三道门：抓取公开网页、读文件、写文档。够用了。工卡这个话题水很深——开哪些门、开到什么程度、错刷了怎么办——深到值得单独一章，我们先按下，这一章只用到最浅的一层。

零件备齐，组装其实是个把它们拧在一起的活：岗位说明书定义它怎么想，记忆喂给它该知道的背景，工具让它做得了事。小雯花了一个晚上搭完第一版——比她预想的快，因为真正的工作量不在搭，而在她过去一年已经在脑子里跑了几十遍的那套流程本身。她要做的只是把流程写成职责，把存货整理成档案，再设一个闹钟：每周日晚上十一点定时启动，跑完把简报放进收件箱。

第一版上线了。然后，照例，翻车。

三、先教明白，再考虑加人

第一个周一早上，小雯打开收件箱，简报确实在，发送时间凌晨一点十二分。那一瞬间她有点感动：这是她一年多来第一个没有献给竞品的周日夜晚。但点开正文，三个问题明晃晃摆着：它把六家竞品的 changelog 几乎全文堆了进来，没有筛选，一页纸变成了九页；它把一条三个月前的旧博客当成了本周新动态；最要命的是，有一家竞品上周悄悄改了定价页，它漏了——而定价变动，恰恰是例会上老板最关心的那类事。

她的第一反应是换模型——是不是脑子不够聪明？换了一个更贵的，第二次跑，九页变成七页，旧闻照旧。第二反应，就回到了那张七个圆圈的架构图：是不是一个 Agent 真的不够？要不要拆一个「筛选 Agent」出来专管去粗取精，再拆一个「核查 Agent」专管查重和时效？

慢着。这两个反应都很典型，也都错了方向。斯坦福大学的研究人员专门研究过这种时刻。他们发现，单 Agent 在复杂任务上翻车，最常见的原因听起来很像人：还没把题目想清楚，就急着给出答案。它抓完几十条动态，没停下来分辨新旧、掂量轻重，顺手就往简报里塞。新员工头一周交上来一份糊掉的周报，你的第一反应不该是给他配两个助理，而是把职责讲得更清楚——解决这个毛病，第一选择从来不是加人，是改岗位说明书。

具体的改法，研究者称为「作答前的脚手架」：在 Prompt 里强制它把预算花在动笔之前的分析上。小雯照着改了她的指令——写简报之前，你必须先做四件事：把本周抓到的所有动态列成清单，每条标注来源和发布日期；剔除发布日期在七天之前的；给剩下的每条按「对我们的影响」打分，并写出打分理由；对比上周存档，专门检查每家的定价页有没有变化。四步做完，才许写简报。

说白了，就是逼它在同一个脑子里多想一会儿，而不是急着开口。第二周的简报，九页变回了一页半，旧闻消失了，定价页的变化也被抓住了。斯坦福的研究对这个现象有句很提气的总结：原本归功于「多 Agent 协作」的那些好处，只要把思考通道用得更到位，在单 Agent 里也能找回来。

他们还给了一条更直接的建议，值得你抄在手边：只要任务能在一个连贯的上下文窗口中完成，且模型能可靠地利用该上下文，就坚持用单 Agent。

那张七个圆圈的图，又被小雯压回了收藏夹。但她心里的痒没消：别人都在搭团队，我守着一个，是不是落伍了？

四、圆圈崇拜：多 Agent 的真理由与假动机

先说公道话：多 Agent 不是骗局，它有真实的用武之地。

最站得住脚的理由是并行。想象你要 AI 帮你安排一趟出差：查航班、订酒店、看目的地天气。这三件事互相不依赖，谁也不用等谁的结果。让一个 Agent 顺序干，是查完航班再查酒店再查天气，三段时间叠加；拆给三个各管一摊的 Agent 同时跑，时间直接砍成最长的那一段。任务能拆成互不依赖的几块时，多 Agent 换来的速度是实打实的。

次要的理由是复用。那个被你调教好的「酒店专家」，懂你的预算习惯、知道你只住带健身房的，下次做「团队 offsite 安排」的流程时，它能整个借走，不用从零再教。听出来了吗？这其实是第 7 章 Skill 资产化的逻辑长到了 Agent 身上——封装得好的能力，天然就想被复用。

小雯的场景里也有这个影子：六家竞品的信息抓取，彼此独立，完全可以并行。这是后话。

但你在网上看到的大多数多 Agent 架构图，动机不是并行，也不是复用，而是一种可以命名的病——圆圈崇拜：评价一个方案的水平，不看它解决了什么问题，看它的架构图画了几个圆圈。七个圆圈摆出来，像一张组织架构图，发出去自带一种「我在搭建 AI 团队」的气势。病一旦有了名字，就可以自查：你此刻想加的那个圆圈，是业务逼出来的，还是发朋友圈需要的？斯坦福那堂课里有一句大白话，专治这种气势：不要为了用而用，能简单就简单，千万不要 Over-design。

这话听着像普通的工程师口头禅。过去两年，不少团队没把它当回事，争相部署多 Agent 系统，几个月后回头一看：API 预算烧穿了，用户在等三个 Agent 接力的响应里流失了，工程师把大半精力花在了调试「谁该把什么传给谁」上。直到你看见账单，才知道这句口头禅有多具体。这笔账单到底怎么产生的，值得单独一节说清楚。

五、编排税：传话游戏的价格

你玩过传话游戏吗？十个人排一排，第一个人看一句话，悄悄复述给第二个，传到第十个人嘴里，「今晚八点楼下集合」能变成「明晚带八个救生圈」。每一次转述都是一次有损压缩，错一点，再错一点，最后面目全非。

Agent 之间传递信息，就是在玩这个游戏。A 抓回一百条原始动态，摘要成二十条交给 B；B 分析完，再压成五条结论交给 C。每一道交接都在做有损摘要，上游的小错不仅没人纠正，还会被下游当成事实接着用。谷歌与麻省理工等机构合作的一项研究给这个游戏标了价：相互独立的智能体集群，会把基线错误放大最多 17.2 倍。不是百分之十七，是十七倍。这就是编排税——每往架构里加一个圆圈，你都在向传话环节纳税。

工具一多，税率更难看。同一项研究测了一个用 16 种工具的集成场景：单 Agent 的协调效率是 0.466，多 Agent 系统只有 0.074 到 0.234，效率折掉二到六倍。研究者专门点了一句：工具密集型任务在多智能体协调下，损耗尤其严重。原因不难想：工具该谁调、结果传给谁、谁对最终输出负责，Agent 越多，这些协调成本涨得越快，真正干活的比例反而越低。一个人用十六件工具，是熟练工；五个人分十六件工具，先得开会讨论扳手归谁。

那为什么那么多多 Agent 系统的测试成绩看着很漂亮？斯坦福的研究人员揭了底：很多亮眼的基准成绩，不过是偷偷消耗了更多算力。当他们把「思考预算」控制住，让两种系统用完全相同的 token 数量推理，单 Agent 在多跳推理任务上持续追平甚至超越多 Agent。每多一个 Agent，意味着更多的通信开销、更多的中间文本、更多让错误翻倍的环节——这些都要花 token，而花在传话上的每一个 token，本可以花在想清楚问题上。同样的钱，与其雇五个人开会传话，不如让一个人多想一会儿。

这笔学费我自己交过。带 XDolphin 的 AI Agent 从 0 到 1 那段时间，我们也画过一张漂亮的架构图，五个角色各司其职，demo 的时候人人点头。真实任务一上量，问题全长在交接处：上游摘要丢了一个关键字段，下游一本正经地基于残缺信息往下推；排查一个错误答案，要翻五份日志才能定位是哪一环说漏了嘴。后来我们把其中三个角色砍掉合并，准确率回升，延迟和成本同时往下掉。那次之后我养成了一个习惯：看到架构图越好看的方案，越要先问一句，这些圆圈是业务长出来的，还是画图的人长出来的？

所以，把强大的单 Agent 当成默认起点，而不是一个等着被替代的弱选项。这是这一章最想钉进你脑子里的原则。

六、四面墙与两种拆法

原则归原则，单 Agent 确实有撞墙的时候。研究者们把墙找出来了，一共四面，你可以挨个对照。

第一面墙，能力饱和。还是那项研究，它的原话是：一旦单 Agent 的基线表现越过某个水平，协作带来的收益就迅速递减。换句话说，多 Agent 真正派得上用场的时刻，是单 Agent 在这个任务上力不从心、再怎么调也上不去的时候。后续有分析把这条结论折算成了一个方便记的数字：单 Agent 准确率还没过 45%，引入多个智能体才有望提升表现。这个数字不是论文原文，别把它当成精确的红线，但当成对抗圆圈崇拜的护身符足够了。反过来读这条更有用——如果你的单 Agent 已经跑到 60%、70%，你还不满意，答案几乎一定在 Prompt 和 Context 里，而不在架构里。先教明白，再考虑加人。

第二面墙，上下文被噪声打烂。如果任务要吞海量、嘈杂、甚至自相矛盾的检索数据，多到把一个连贯的上下文窗口搅得七零八落，那让几个 Agent 先分头过滤、组织这些噪声，再汇总推理，就有正当理由。典型场景是大规模舆情或文献分析：几千条相互打架的评论和报道塞进同一个窗口，第 6 章讲过的 Lost in the Middle 会让模型读着读着把关键信息漏掉，这时候分头消化、各自提纯、再合并，才是对的。

第三面墙，任务有天然的拆分边界。子任务能完全独立处理，比如出差安排里的航班、酒店、天气，或者让一个金融 Agent 分别跑营收分析和市场对比，拆开并行就有可观的收益；反过来，任务必须按顺序一步咬一步，就老老实实留在单 Agent 里。

第四面墙，就是前面说的并行本身：你等不起串行的时间。

真要拆了，怎么搭？推荐的姿势叫层级式（Hierarchical）。拿智能家居打比方：你回家说一句「我到家了」，对话的永远只有一个管家，由这个编排者（Orchestrator）把活派下去——温控 Agent 去调空调，安防 Agent 去撤防，灯光 Agent 去开玄关的灯，最后管家汇总一句「都办妥了」。你不用挨个跟三个 Agent 打招呼，它们之间该商量的事，可以在后台直接水平沟通，省掉中间人来回传话的成本。对外一个口，对内各管一摊，这就是层级式的全部要义。

这里有一个一旦想通、设计就豁然开朗的心态：把 Agent 当作 Tool 来调用。对编排者来说，那个「航班专家」不是同事，就是一件工具，跟「抓取网页」这个工具没有本质区别，输入需求，返回结果。你不需要发明什么新的协作哲学，你只是在给一个 Agent 配更高级的工具，而这些工具碰巧自己也会思考。

拓扑上还有一个讲究。如果任务工具高度密集，超过十种，本来就该优先单 Agent；实在非拆不可，就选去中心化的结构，让各个 Agent 彼此辩论各自的答案，而不是全部听一个中枢指挥。实验数据是：去中心化方案开销更高，但成功率 66.4%，优于中心化的 62.1%。

但有一类场景要反着来：医疗、金融这种强监管行业，错一条就可能是合规事故，这时候中心化反而是对的。让一个编排 Agent 统辖所有子 Agent，先交叉核对它们的推理过程和输出结果，再放行最终答案。研究者的原话是：关键差别在于，必须有一个显式的验证关卡，把错误拦在最终输出之前。注意「显式」这两个字的分量——这个关卡不会自己长出来，你得明明白白地把「拦截哪几类失败」编进编排器里，就像银行柜台的复核岗，岗位职责是一条一条写死的，不靠柜员的自觉。数字也支持这一手：交叉核对能让逻辑矛盾减少 36.4%，由编排器做最终综合，能让上下文遗漏减少 66.8%。一句话，要快，去中心化；要稳，中心化加关卡。

七、五问决策矩阵

到这儿，单和多的取舍，可以收拢成一张你随时能用的决策矩阵。下次站在「要不要拆」的路口，按顺序问五个问题：

工具密集吗？要集成的工具超过十种，选单 Agent；非用多 Agent 不可，就用去中心化结构换并行效率。
失败是因为想得不够深吗？输出总是草率、没想清楚就作答，留在单 Agent，往 Prompt 里加「作答前脚手架」，逼它先分析再动笔。
失败是因为上下文被污染吗？输入海量、嘈杂、自相矛盾，连贯窗口已经保不住，转向多 Agent，让它们分头过滤和组织。
有天然的拆分边界吗？子任务完全独立，拆开并行；必须按顺序咬合，留在单 Agent。
输出要过合规审核吗？要，就上中心化多 Agent，把验证关卡显式地编进编排器，拦截逻辑矛盾和上下文遗漏，再放行。

注意这五问的排序不是随便排的：前两问都在劝你留下，第三、四问才给你放行的理由，第五问管的是怎么拆才安全。这个顺序本身就是态度——升级架构是最后的手段，不是第一反应。

还有一件配套的事，决定这五问答得准不准：评估纪律。第 12 章会专门展开，这里先立个桩。「单 Agent 准确率有没有过 45%」「失败到底出在推理还是上下文」，这些判断没有一个能靠感觉回答，全要靠日志和测试集说话。用开源模型，你可以直接测推理轨迹、控制 token 预算；用闭源模型，就拿成本和响应时间当代理指标。一套像样的日志系统，能让你随时看清自己的架构在成本与准确率之间站在哪个位置——没有这套东西，五问就是五道玄学题。

小雯把自己的场景按着五问过了一遍。工具就三种，远不到密集；曾经想得不深，加了脚手架已经治好；信息源就六家，干净得很；竞品简报也不用过什么合规审查。唯一沾边的是第四问，六家的抓取彼此独立。于是她的最终架构是：还是那一个 Agent，只是抓取这一步让工具并行去跑，六家同时抓，跑完汇到同一个脑子里分析。

注意，这不是在单与多之间和稀泥，而是第三种姿态：单与多本来就不该是一道选边题，该并行的是手脚，不是脑子。判断这种事，一个脑子从头想到尾，比六个脑子开会靠谱。没有七个圆圈，一个就够，但这一个是被教明白的。

八、委托执行，不委托责任

现在的小雯，周一早上八点四十打开电脑，简报已经躺在收件箱里：本周三条重要动态，每条带原文链接、带影响判断、带一句「建议关注」的理由；有一条标着「未能核实：原文在付费墙后」。她花十分钟核一遍，改掉一个她不同意的判断，九点半进会议室。她的周日晚上，整块地回来了。

注意她还在做的那件事：核一遍，改一个判断。第 2 章说过，委托执行不等于委托责任，简报发到例会上，署的还是她的名字。Agent 替她搬走的是两个小时的体力活，替不掉的，恰恰是当初让这件事值得她做的那十分钟判断。这十分钟，就是她跟一台爬虫的区别。

还记得第 2 章那四级台阶吗？第三级叫驱动，跨过去的标志是：你至少有一条流程，是你睡觉的时候它也在跑的。当时你读到这句，可能觉得那是程序员的特权。现在回头看，小雯没写过一行正经代码，她有的只是被这本书反复打磨的几样东西：一套说得清的判断标准，一份理得顺的流程，和一点「先教明白一个，再考虑第二个」的定力。周日晚上十一点，她睡了，她的 Agent 准时打卡上班。那级台阶，她是真的站上来了。

本章要点清单

Agent 等于决策加工具加记忆：少决策是流水线，少工具是军师，少记忆是每周一失忆的临时工。评估任何自称 Agent 的东西，先照这三样。
岗位说明书就是 Prompt 的升级：从「一次任务」到「一个岗位」。对话框翻车丢五分钟，说明书翻车会用同一个姿势安静地错上一个月——版本化、测试集、改完重跑，从建议变成必须。
翻车了先别换模型、别加人，先改说明书：加「作答前的脚手架」，逼它先分析、再动笔。多 Agent 的好处，思考通道用到位，单 Agent 里也能找回来。
把强大的单 Agent 当默认起点。45% 是对抗圆圈崇拜的护身符数字：准确率没跌破它，答案在 Prompt 和 Context 里，不在架构里。
编排不是免费的：每一道交接都是有损压缩，独立智能体集群最多把错误放大 17.2 倍；花在传话上的每一个 token，本可以花在想清楚问题上。
真要拆，照五问拆；要快，去中心化；要稳，中心化加显式验证关卡。
并行的是手脚，不是脑子。
委托执行，不等于委托责任——Agent 搬走体力活，替不掉那十分钟判断。

小结

这一章从小雯的周日晚上出发，把「搭一个 Agent」这件听起来很工程的事，还原成了一次招聘。Agent 由决策、工具、记忆三样构成，其中两样你早就打过地基：第 5 章的指令升级成岗位说明书，给它章法；第 6 章的记忆整理成交接文档，给它来历；这一章只是把零件拧紧，再发给它一张工卡。第一版必然翻车，而翻车之后的正路不是换模型、不是加人，是把这个人教明白——作答前的脚手架，逼它先想后说。至于七个圆圈的诱惑，我们把账算清了：编排税会把错误放大十几倍，多数漂亮的架构图源自圆圈崇拜而不是业务；数据撑腰的那条线是 45%，没撞到四面墙之前，守住一个被教明白的 Agent；真要拆，照五问拆，要快用去中心化，要稳加验证关卡。小雯最后的架构，是这套原则的活样本：并行的是手脚，不是脑子。

不过，她的故事还没完。用了一个月，她开始不满足了。Agent 看得到公开网页，却进不了公司内部的客户数据库，没法把竞品动态跟「我们哪些客户也在用他们」对上；它写得出简报，却发不了真正的邮件、建不了工单，最后一公里还得她自己跑。有一次它在简报里写「竞品 C 的新功能可能威胁我们的大客户续约」，判断很准，但「哪些大客户」它答不上来——那份名单躺在它够不着的 CRM 里。她搭好的这个下属，聪明、勤快、记性好，可手里那张工卡，说到底只是一张访客证，进不了核心系统的门。

这就是下一个问题：Agent 搭好了，它能干多大的活，不取决于它有多聪明，取决于你给它接上什么工具和系统，以及你敢放给它多大的权限。把它接进真实世界，同时在该画线的地方画好线——是下一章的事。