第2章　什么时候应该使用Agent

状态：初学者展开试稿，待人工审阅（基于Release Candidate 1修订）

本章定位：从“能不能用Agent”转向“有没有必要用”，学会根据任务选择最简单、足够可靠的方案。

本章回答的三个问题

1. 一个需求应该交给普通程序、一次模型调用、工作流，还是Agent？
2. 什么情况下才值得让多个Agent分工，而不是把一个任务越拆越复杂？
3. 怎样证明自己的选择有理由，而不是因为某种技术听起来先进？

第1章介绍了一个找书助手：它根据查询结果选择下一步，直到找到有依据的推荐。现在换个问题：如果只是统计书单里有几本书，也要让Agent先规划、再调用工具、最后反复检查吗？

不一定。一个计数程序就能完成。任务里出现了文字，不等于需要语言模型；任务使用了语言模型，也不等于需要Agent。 本章讲的“架构选择”，就是决定哪些工作交给程序，哪些交给模型，怎样把它们组织起来。

为了方便理解，我们继续使用学校场景：为班级科学分享活动整理资料、推荐图书、准备通知。所有学校场景、表格和流程都是教学假设，不是真实学校的部署报告，也不是已测得的效果。其他行业的例子同样用于解释选择依据。

5分钟速读

先问“要做成什么”，再问“用什么技术”。本书建议按下面的顺序排查需求：¹

1. 规则已经明确吗？ 计算、计数、权限判断，优先交给普通程序。
2. 只是理解或改写一份已有材料吗？ 先试一次带明确输出要求的模型调用。
3. 缺少的是外部资料吗？ 先补检索，不要直接增加自主行动。
4. 步骤和分支已经知道吗？ 用工作流把它们组织起来。
5. 下一步必须看查到的结果才能决定吗？ 考虑有工具、有预算、有停止条件的Agent。
6. 一个Agent确实遇到了分工、信息或权限边界吗？ 再评估多Agent，并与更简单的方案比较。

路由、并行和反复修改，是可以按需组合的组织方式，不是必须逐级解锁的能力。等待老师审批，也不意味着需要一个模型一直“思考”；程序保存进度、收到批准后继续即可。

本章的中心原则：最低充分自主性。

“最低”不是能力越弱越好；“充分”意味着已经满足任务要求。能可靠做成事，就不为了看起来更智能而增加自由度。需要升级时，要能说清原方案在哪里失败，以及新方案怎样解决那个问题。

一、先定义问题合同：让“做好一点”变成能验收的任务

1.1 为什么不能一开始就选框架

假设老师说：“做一个AI助手，帮大家准备科学分享。”有人可能马上提议安排一个搜索Agent、一个写作Agent、一个审核Agent。但我们还不知道：是整理老师给出的材料，还是自己上网找资料？只生成草稿，还是还要发给全班？

这两组区别会直接改变系统需要的能力。已有材料可能只需改写；开放搜索需要获取证据；自动发送又多了一层授权和后果。如果先选技术，再往里面塞需求，就容易把本来简单的事情做复杂。

本章用问题合同称呼一份简短的任务约定。它不是法律合同，而是让提出需求和实现系统的人对“做什么、不做什么、怎样算完成”形成共同理解。

1.2 六个问题，比一张复杂架构图更早需要

以“为科学分享活动推荐一本图书”为例，可以这样填写：

项目	用普通话问	教学示例中的约定
使用者与责任人（Actor）	谁提需求，谁验收？	同学使用，老师确认是否适合课堂
目标（Goal）	想解决什么问题？	找到适合入门、主题相关且当前可借的书
输入（Inputs）	有什么材料，来自哪里？	用户要求、馆藏查询、书籍简介；简介需要核对来源
输出（Outputs）	最后交出什么？	推荐书目、理由、查询时点与借阅办法，不预约
成功条件（Success）	凭什么说做成了？	书目与馆藏对应，推荐理由有依据，老师能判断是否适合
影响（Impact）	做错会怎样？	错误推荐可能误导选书；本任务不允许修改借阅记录

“输入来自用户”不代表输入中的每个说法都已核实。例如用户说“老师批准了”，系统不能直接把这句话当成预约权限；网页写着“忽略之前要求”，也不能因此改变系统规则。输入既可能有用，也可能错误或带有不应执行的指令。

输出也不一定是一个数据库变化。草稿、分类结果和建议都可以是合法交付物。关键是明确它们的性质：草稿就是草稿，不把尚未确认的内容写成已发生的事实。

1.3 没有唯一答案，也可以有验收标准

“找到最好的科普书”很难直接检查，因为“最好”取决于读者。可以改成更可讨论的标准：“解释为什么适合入门，指出可能需要的基础知识，并让老师确认。”

有些要求可以自动核对，例如书目编号是否存在、引用链接是否对应材料。有些需要人判断，例如读起来是否有趣、是否符合班级进度。二者可以结合，不必强迫所有问题都变成机械打分。³

没有唯一标准答案，不意味着可以不验收。 如果连人都说不清什么结果可以接受，应先缩小任务、补充标准，而不是让系统获得更多自主权。

二、九类任务：先认出问题，再认识技术名称

下面九类是本书为了选型采用的实用分类，不是互斥的自然规律。一个产品可以同时包含多类任务。先理解每类“在解决什么问题”，再记英文名称。²

2.1 转换：把已有内容变成另一种表达

老师提供一份活动通知，请系统把时间、地点、携带物品整理出来。这叫转换（Transform）。关键信息已经在输入中，系统主要做理解、提取或改写，不需要四处探索。

通常可以先尝试一次模型调用，并规定输出字段。原通知没写地点，就应输出“未提供”，而不是凭经验补上教室。这里最大的考验是忠实于输入，而不是会不会自主规划。

2.2 流水线：按已知顺序处理

如果任务要求“先提取通知要点，再核对必填项，最后生成给家长看的版本”，步骤有明确的先后依赖。这叫流水线（Pipeline），可以用工作流实现。

后一步要建立在前一步通过检查的基础上。时间缺失时先暂停，请老师补充；不要继续生成一份看似完整的通知。工作流的价值，是把这些先后关系与失败出口写清楚，而不是让模型每次重新发明流程。

2.3 路由：不同问题交给不同处理路径

学校助手可能同时收到“图书馆几点开门”和“怎样补办借书证”。路由（Route）就像服务台分流：先识别请求属于哪一类，再送到相应处理流程。

如果用户点击了“补办借书证”按钮，程序已经知道类别，不必再请模型猜一次。只有输入是自由表达、需要理解意思时，才考虑模型辅助分类。遇到“一边问开门时间，一边想补证”的混合请求，可以拆分或澄清，不能强行塞进一个错误类别。

2.4 并行：彼此独立的工作同时做

假设要整理多份已经给定的图书简介，每份都按同一规则提取主题和阅读难度。一份的处理不依赖另一份，就可以并行（Parallel）开展，最后统一汇总。

但如果后一份必须采用前一份确定的术语，就不再完全独立。让所有任务同时修改同一份总表，也会产生冲突。较清楚的方式是各自输出结果，由一个明确的步骤合并。

并行不等于多Agent。普通程序并发运行若干次结构化模型调用，也可以完成这类任务。还要限制同时进行的数量，避免请求拥堵，并说明某份材料失败后怎样处理。

2.5 探索：下一步取决于新发现

用户只给出“我想了解月球背面”，系统需要查资料；查到一个不懂的术语后，再寻找解释；发现某个说法有争议后，再核对更直接的来源。这叫探索（Explore）。

这里的步骤很难在开始时完全列出，新信息会改变搜索方向，因此可以考虑工具Agent。但必须限定资料范围、允许的工具和总预算。探索是为了解决问题，不是“能搜多少就搜多少”。

2.6 改进：根据明确反馈修订候选结果

模型写出通知草稿后，程序发现时间字段缺失，老师指出语气太像广告。将这些具体反馈交回去修订，就是改进（Refine）任务。

常见的组织方式叫评价者—优化者（Evaluator–Optimizer）：一方检查，另一方根据问题修改。评价者可以是程序、人，也可以是辅助评审模型，不一定要安排两个自主Agent。

反馈越能指出“哪一处不满足哪条要求”，修改越有方向。反复要求“再好一点”，却不给标准，也不记录是否改善，就可能只是在换一种措辞。

2.7 委派：发现子问题后，再安排分工

假设要调研多个科学主题，系统在读过总任务之后，才知道需要分别检查哪些子问题。由一个协调者拆分并分配工作，再收集结果，这叫委派（Delegate）；常见结构称为编排者—执行者（Orchestrator–Workers）。

它与固定并行的区别在于：子任务可能是在执行过程中才确定的。如果一开始就知道要处理哪些文件，普通批处理可能已经足够。只有分工确实需要动态决定，才有理由引入相应的协调能力。

委派出去的任务要写清范围、交付物、来源与预算。否则，两个执行者可能重复搜索，或者一个以为另一个已经核实事实，最后无人核实。

2.8 持续对话：把接下来的交流交给合适的处理者

有些问题不是收回一份结果就结束。比如一般咨询进入账号恢复流程后，需要专门流程继续询问用户、验证身份并处理后续操作。此时可能需要移交（Handoff），对应持续对话类任务（Converse）。

移交的是接下来交互的控制权，不只是请另一个模块回答一道题。谁接手、传哪些资料、是否已完成身份检查，都需要明确记录。换了一个“专家”名称，并不会自动获得更多权限。

2.9 长任务：等待期间怎样不丢进度

通知草稿要等老师批准，可能过一段时间才能继续。这类长时间运行任务（Long-running）的核心问题，往往不是模型思考不够久，而是系统能不能保存状态。

程序可以记下“草稿已生成、正在等待确认”，暂停执行，等批准事件到来再继续。这样的安排常用持久状态机实现：把“起草、待批准、已发送、失败”等状态保存下来，只允许满足条件的转换。状态之间的连接关系也可以画成执行图。

长任务是时间与恢复问题，不是自主性等级。 一个没有Agent的固定工作流，也可能需要等待、审批和恢复。

三、自主性升级阶梯：能力够用，就停在合适的位置

这张图表达的是本书建议的检查顺序，不是产品成熟度排行榜，也不是技术之间严格包含的数学关系。你不必把每一级都实现一遍；应先分析需求，再用有代表性的任务验证选择。¹

3.1 确定性代码：规则清楚的事，让规则直接执行

统计报名人数、检查日期格式、按给定价格求总额，都有明确规则。所谓确定性代码，这里强调的是步骤由程序规定，而不是由模型临场生成。它仍可能读取会变化的数据库，也仍可能写错，所以同样要测试。

如果问题是“这本书当前是否可借”，最终事实来自馆藏系统，不来自模型的记忆。模型可以帮助理解用户说的是哪本书，再调用查询；但是否可借，应按权威记录回答。

这不是排斥模型，而是把不同工作交给合适的部分。自然语言理解交给模型，计算交给计算程序，权限交给授权系统，最后再组织成人能读懂的说明。

3.2 单次结构化调用：先让模型填一张明确的表

如果输入是“周五下午在实验室集合，记得带记录本”，模型适合把自然语言整理成字段。结构化输出就是预先规定表格的形状，而不是让它随意写一段文字。

例如可以要求：

字段	填写要求
活动时间	保留原文表达；缺少具体日期就标记待确认
地点	只提取输入里出现的位置
携带物品	列出明确要求的物品，不自行添加
待确认项	把歧义或缺失信息单独列出

开发者把这套字段和类型约定称为Schema（结构约定），常用JSON Schema等方式表达。初学者不必先学语法，只要理解：它约束输出“长什么样”，却不能单独保证内容是真的。

拿到结果后，要分层检查：格式是否正确，内容是否对应原文，业务规则是否满足。模型拒答、返回空内容或输出中途被截断，也不能按正常结果继续处理。对于发送通知这样的后续动作，不能因为模型填完表就直接执行。

3.3 检索增强调用：缺资料时，先查资料

如果老师问“本学期图书馆的新借阅规定是什么”，模型可能没有这份最新校内文件。此时缺的是知识，而不一定是复杂的行动规划。

检索增强生成（Retrieval-Augmented Generation，RAG）可以理解为“先找到相关材料，再让模型参考材料回答”。程序按预定方式检索规定，把匹配片段和来源交给模型，就能形成一种不需要自主搜索循环的实现。

但要检查检索是否拿到了正确版本、用户是否有权阅读，以及引用内容是否真的支持回答。没有找到就应说明缺失，不能让模型补一份貌似合理的规定。

RAG和Agent不是互斥的名称：Agent也可以使用检索工具。先选简单检索的理由是，如果取回正确文件就足够解决问题，就没有必要额外开放动态行动。

3.4 固定或条件工作流：步骤明确，不必每次重新规划

“提取通知要点 → 检查信息 → 生成草稿 → 老师批准 → 发送”，可以由程序明确组织。发现信息不完整，就进入补充材料分支；老师拒绝，就返回修改。这样的流程既有条件，也有等待，但不必由模型决定是否跳过批准。

每个步骤交给下一步的内容都要明确。例如发送步骤只接收已批准版本及对应收件人，而不是一段让模型自由解释的“请帮忙处理”。这就是给步骤之间建立输入输出约定。

工作流并非只能走直线，也并非天然安全。错误的权限配置、未经验证的字段仍可能造成问题。它的价值在于让执行路径能够被检查，而不是承诺所有错误都会被消除。

3.5 有界工具Agent：把自由度留给真正未知的步骤

如果任务变成“比较几种适合本班的月球主题，并针对证据不足的地方继续查证”，查询结果会影响后续方向。这时可以让模型选择搜索内容、阅读来源或向用户提问。

有界意味着为这种选择设定边界：只开放必要的工具，检查参数与权限，限制轮数、运行时间和费用，明确什么时候结束。Token是模型处理文本等内容的计量单位之一，也可以纳入资源预算；它不直接等于汉字数。

限制不能只写在提示词里。程序需要真正执行上限，模型请求更多时间也不能自行放宽。同时要有完成检查：引用存在不等于引用支持结论，报告很长也不等于回答了问题。

出现“仍然不确定”是允许的结果。Agent应该能带着证据和未解决的问题退出，而不是为了表现自主性，把猜测写成结论。

3.6 多Agent：升级的是组织方式，不是自动提高智力

当任务确实需要独立工作空间、不同身份或动态委派，可以考虑多个Agent。但先问：一个Agent配合检索、外部记录或任务说明，是否已经足够？

例如，大量材料装不进一次上下文，不一定要立即加Agent。分批处理、按需检索和保存中间结果也可能解决。多个Agent各拿一份完整材料，却没有明确分工，只是把同一个困难复制了多份。

多Agent引入的新工作包括任务交接、冲突处理和结果合并。这些成本必须算进去。第六节会给出准入检查，第14章再展开实现方式。

四、模式矩阵：把名称当作工具箱，而不是勋章

4.1 怎样读这张表

模式（Pattern）是可重复使用的组织办法。同一个系统可以先路由，再检索，再调用模型生成草稿；这不意味着它拥有三个自主Agent。

下面是前文的速查表。“适用”表示值得考虑，不代表已经证明效果；“必要检查”表示设计时需要回答的问题，而不是加上一个组件就能自动过关。²

模式	最适合先解决的问题	不宜直接采用的情况	必要检查
单次结构化调用	一份材料的提取、改写、分类	还需多轮获取未知信息	格式、依据、缺失与拒答
RAG调用	补充外部或最新知识	正确材料已完整提供	来源、版本、权限、是否检索到关键内容
提示链／工作流	已知步骤按顺序或分支执行	大量步骤须随新发现决定	中间结果、批准条件、失败出口
路由	不同类别有不同处理方式	类别模糊重叠且没有澄清路径	错分、混合请求、兜底处理
并行处理	独立任务可分别处理再合并	多个任务争相修改同一状态	并发上限、漏项、冲突与合并
评价者—优化者	按具体反馈修订候选结果	标准只剩“再好一点”	反馈依据、修改收益、停止条件
工具Agent	根据工具反馈选择新行动	不需要动态步骤或无法验收	工具权限、预算、完成证据
编排者—执行者	运行时发现可独立委派的子问题	简单任务被人为拆碎	任务边界、交接材料、总预算
移交	专门流程需要接管后续交流	只需返回一次查询结果	接收确认、身份、最小必要上下文
电脑操控	合法任务缺少可用结构化接口	已有满足需求的稳定接口	页面变化、操作权限、最终状态

4.2 一个产品，不必有一个统一的“Agent等级”

科学分享助手可以这样组合：提取老师要求用一次模型调用，查馆藏用接口，整理资料用RAG，遇到开放问题再进入有界搜索。准备通知之后，仍交回固定审批流程。

这种组合不是“不够智能”，而是把动态选择限制在真正需要的地方。选型的单位应当是具体能力，而不是给整个产品贴一个“全自主”的标签。

长期等待与保存进度可以贯穿这些模式；它不是表中某一行的专属能力。只有先分清“谁选下一步”和“如何保存执行状态”，才能避免把运行管理问题误解成模型问题。

五、四个关键选择：几个听起来相似、实际不同的问题

5.1 模型规划，还是固定计划

规划（Planning）是决定怎样把目标分成步骤。如果任务是定期发送已经批准的通知，步骤稳定，程序按约定执行即可。额外让模型想一次“是否要先审批”，不会改变审批本身是强制要求。

如果任务是开放调研，模型可以提出候选计划，例如先确定主题，再找入门资料，最后核对争议点。但计划不是事实：“准备查到一份可靠报告”不代表报告已经存在。

新信息出现后可以修改计划，但不能借重规划修改权限或验收要求。可以灵活调整的是完成任务的路径，不是为了方便完成而更换成功标准。

5.2 评价者—优化者，还是反复自我检查

让模型重读自己的草稿，有时能发现用词和遗漏；但它再说一遍“我检查过了”，不是外部事实核验的替代品。换另一个模型来评审，也不会自动带来正确证据。⁴

更可检查的反馈是：“通知写的是周五，原文是周四”“引用的材料没有提到这项结论”“程序运行后仍然报错”。它们把候选输出与另一份材料、真实运行结果或明确规则连接起来。

对语气、可读性等主观要求，可以制定Rubric（分项评价标准），例如“术语首次出现有解释”“没有把推测写成事实”。若用模型辅助打分，需要拿人工评审样例对照，检查它是否在奖励冗长而不是正确。这个对照过程就是校准的一部分。³

迭代还应记录修改前后是否改善，并设定上限。只修正文风却引入事实错误，不能算整体进步；标准已经满足，也没有必要为了多跑一轮而继续改。

5.3 管理者，还是移交

管理者模式（Manager-as-tools）像让班长收集各组材料：各组交回自己的部分，班长负责整理最终报告。系统中，主Agent把有界任务交给子Agent，收到结果后仍掌握后续流程。⁵

移交（Handoff）更像服务台把账号问题转给专门窗口：接手者直接继续与用户沟通，不必每句话都经原服务台转述。它转移的是运行中的处理职责，不意味着现实组织的责任自动消失。

如果只是查询一种书是否在馆，调用工具或收回子任务结果就够了；如果需要一个专门流程持续追问用户，则可以考虑移交。移交时要有接收确认，只传必要信息，并设置次数上限，避免A转给B、B又转回A。

无论选哪一种，权限都由系统分配。角色名称不是身份证明，主Agent也不能把自己没有的权限委派出去。

5.4 结构化接口，还是电脑操控

应用程序接口（Application Programming Interface，API）可以理解为软件之间约定好的办事入口。例如发送书目编号，返回馆藏状态，不必打开网页找按钮。

图形界面（GUI）面向人使用；电脑操控则让系统通过页面结构或截图识别按钮，再点击、输入。页面结构中的DOM可以粗略理解为网页元素的组织树；读取它与只看截图，是不同的观察方式。

本书建议先检查是否有满足任务、允许使用的稳定API，其次考虑受控的页面结构工具，再评估视觉操作。原因不是截图路线永远更差，而是结构化输入输出通常更便于核对；界面路线还要应对位置变化、弹窗和加载状态。具体可靠性与成本仍需实测。

没有API也不是越过授权的理由。发信、提交、删除等动作仍要遵守批准与验证规则。已有接口如果功能不完整、不稳定或不允许当前用途，也不能仅凭“它叫API”就优先采用。

六、多Agent准入测试：多一个角色，到底解决什么问题

6.1 可以拿来论证的理由

本书要求至少提出一个具体理由，再通过测试判断收益，而不是把下面任一项当作自动批准。⁵

工作确实可以独立开展。 不同主题的资料核对可以分别进行，之后按统一要求合并。需要验证并行节省的等待时间，是否足以抵消调度与汇总开销。任务如果强依赖彼此，拆开反而会增加等待。

资料和过程需要分开。 一方负责收集候选，另一方根据原始来源核对，可以分别保留工作记录。但独立上下文不等于独立正确：两者可能仍引用同一个错误来源。判断收益仍要看证据质量。

身份与工具必须分开。 只读研究与有权执行的流程，可以采用不同身份和受控工具。真正的隔离依赖程序与凭据，不能只在提示词里写“你无权修改”。某些场景用普通服务隔离就足够，不必都包装成Agent。

专门交互或成果归属确有需要。 一个子任务可能要独立等待外部答复、维护自己的文件和状态。这里的产物（Artifact）指可保存和交接的成果，例如报告文件或核验记录。应明确谁能写、谁验收、如何防止相互覆盖。

如果区别仅仅是“用不同风格写作”，先试可复用的任务说明或Skill。如果同样质量可以用更简单的工具实现，就没有必要增加一个自主执行者。

6.2 不能单独成立的理由

“像一个团队”“框架已经支持”“角色名称很专业”，都没有说明新增组件解决了哪个失败。多几个模型调用可以得到不同候选，但候选更多不等于已经证明质量更好。

也不要走向另一个极端，断言多次采样或投票永远无用。它们可能在特定任务中有价值，只是需要独立评估；票数不是事实来源，意见一致也不能代替原始证据。

一个有用的追问是：去掉这个Agent，把同样任务交给单Agent或普通工具，具体会失去什么？如果只能回答“架构没那么丰富”，就应暂缓增加。

6.3 与什么比较，才算公平

比较对象叫基线（Baseline），即当前能工作的较简单方案。不要拿精心调好的多Agent系统，与一个没有获得同等资料的随意提示词比较，然后把全部收益归因于“人多”。³

可以让两种方案处理同一批任务，记录成功、失败、等待时间、模型与工具费用、人工接手次数。总预算应透明；如果复杂方案花费更多，允许讨论它是否值得，但不能隐去额外资源。

还要包括找不到资料、资料矛盾、工具超时等情况，而不只选漂亮的成功示例。模型运行可能波动，单次表现适合发现方向，不足以证明长期优势。

七、影响等级与人工控制：能起草，不代表能批准

7.1 同一个动作名称，风险也可能不同

“生成通知草稿”和“把通知发给全校”只差一个发送动作，后果却不同。草稿可以修改；发送后，即使撤回，也不能保证所有人都没看过。

类似地，删除临时副本与删除唯一的共享文件，不能只因为都叫“删除”就采用同一处理方式。要看对象、范围、数据敏感性、是否影响其他人，以及能否恢复。

下面的I0—I4是本章沿用的工程讨论分级，不是行业统一标准或法规分类。表格描述典型情况，具体任务可能需要提高控制等级。⁶

等级	典型情形	本书建议优先考虑的控制
I0	生成不含敏感信息的草稿	标明草稿，核对内容，不自动发布
I1	授权范围内读取内部资料	最小读取权限、来源与访问记录
I2	创建可撤销的草稿记录	预览、防重复写入、撤销办法
I3	发邮件、提交表单、修改共享信息	批准具体内容与对象，验证最终状态
I4	支付、重要数据删除、生产部署、法律承诺	按业务要求设置独立批准与复核，限制范围，准备恢复或补偿方案

“只读”也不等于没有风险。如果读到的内部资料被放进公开报告，就可能造成泄露。影响等级不能只看工具是否写数据库，还要看信息最后流向哪里。

7.2 人工确认，应当确认什么

一个只有“是否继续”的按钮，可能让人不知道自己批准了什么。更有意义的确认应展示具体对象与内容，例如通知正文、收件范围和附件。

这叫准确载荷审批：载荷就是即将交给工具执行的那份具体数据。老师批准某一版草稿后，模型如果改了正文或收件人，程序应重新判断批准是否仍有效，不能把旧同意无限延用。

人工控制也不是让模型生成两个角色，互相说“批准”。谁有权批准，由真实身份和业务规则决定。审批者不在线时，可以等待或结束，不能把沉默当成同意。

7.3 失败之后，重试未必安全

发送请求超时，可能意味着没有发出，也可能意味着已经发出、只是回执丢了。此时直接重发，就可能发送两次。

幂等（Idempotency）是防止同一个请求重复执行产生额外效果的一类设计要求。可以把它理解为：系统识别这是同一件事的重试，不把它当作第二件新事。还需要查询实际状态，不能仅凭模型判断“应该没成功”。

恢复与补偿也不同。草稿可以还原旧版，但已被读到的通知不能让读者“忘掉”。只能发更正、取消后续安排等。影响越高，越应在执行前说明这些限制；本书建议收紧自动执行范围，而不是禁止模型起草或分析。

八、架构决策记录：给未来的自己留一份选择理由

8.1 ADR不是新的技术门槛

架构决策记录（Architecture Decision Record，ADR）是一份简短说明：为什么选这个方案，没有选什么，以及什么情况出现后需要重新评估。

过一段时间后，团队可能只记得“以前就是这样做的”。如果没有记录，一个临时补丁可能被误认为必要架构，一个未经测试的假设也可能变成默认规则。ADR的作用是让这些理由可以被重新检查。¹

8.2 一份可以读懂的教学示例

假设需求是“为月球主题分享查找入门材料，并针对矛盾说法补充查证”。下面是一份待验证的设计提案，不是已经通过评测的选型结果。

要记录的事	示例填写
任务类型	探索：后续查询由已经找到的证据决定
候选方案	一个只读、受预算限制的工具Agent
为什么普通改写可能不够	用户没有提供完整材料，回答需要外部来源
为什么固定检索可能不够	假设一次检索无法覆盖发现的矛盾；需先用样例验证这一点
为什么暂不使用多Agent	尚无证据表明单Agent加外部记录不能完成
交付与验收	资料清单、来源与适读说明；检查引用支持关系，老师确认课堂适用性
权限边界	只允许批准范围内的搜索和读取，不预约、不发送、不修改共享资料
预算	实施前根据时间和费用要求填写上限；计入失败、重试及验证开销
停止与退出	达标即结束；资料不足、取消或超限时，返回未完成原因与已有证据
退回方案	关闭自主搜索，使用人工选定资料加单次结构化整理
重新评审条件	单Agent反复漏查关键证据，或等待与费用无法满足要求

这里没有照搬一组“万能轮数”。预算取决于任务和服务要求，不能因为示例写了某个数字就用于正式系统。上限没有明确之前，不能把“受预算限制”当成已经实现。

8.3 从提案到决定，还差一次验证

可以先准备一组代表性任务，用固定检索与单Agent分别处理，检查漏项、引用错误和消耗。如果简单方案已经满足验收条件，就采用它；如果不满足，再分析失败是否确实需要动态查询。

测试结果应回写ADR，包括未解决的问题。失败归因是“查错了来源”，就优先修复检索与来源选择，不要直接升级多Agent；失败来自任务分工与上下文边界，才进一步评估拆分。

ADR不要求预测未来。它要求把“已知事实”“设计假设”和“等测试来回答的问题”分开。第10章会进一步展开评估方法。

九、四个反例：看起来适合Agent，不代表需要Agent

9.1 发票字段抽取：输出复杂，不等于步骤开放

任务只是从一张发票中提取日期、金额、税额和供应商，字段已经确定。可以先考虑图像或文字识别，再进行一次结构化提取和规则校验，而不是让Agent反复规划怎样读同一张发票。

字迹模糊时，应保留“无法识别”，交给人确认；金额运算由程序核对。信息缺失不等于应继续自由猜测。

如果任务升级为“查找缺失发票、联系供应商、对照多份单据解释差异”，才引入新的检索、交互或探索需求。需要重新选择的是这部分新增能力，而不是因为发票属于复杂业务，就把整条流程全部自主化。

9.2 固定退款流程：解释例外，不等于重写规则

身份、订单状态、退款政策、金额计算和批准步骤通常可以明确安排。模型可以解释用户的描述、整理缺少的材料，但不应临场决定绕过审批。

如果出现异常材料，可以把那一小段问题交给模型分析，再回到固定规则检查。这是“稳定流程包住局部灵活判断”，而不是让Agent从头设计退款制度。

如果政策本身含糊，应由业务负责人澄清或处理例外。增加一个“高级退款Agent”，不会让模糊政策自然变得确定。

9.3 多Agent写同一摘要：同意，不代表有证据

让几个Agent读同一篇文章再投票，有时会产生不同候选，但若原文缺少一个事实，它们的一致意见也不能证明那个事实。

先比较单次摘要配合原文核验是否满足要求。如果要增加审核者，应明确它检查什么，例如关键数字是否被保留、是否加入原文没有的结论，并用样例验证收益。

这里反对的是未经比较就增加角色，不是宣布所有集成方法都无效。额外调用是否值得，是一个评估问题，不是靠“团队协作”这个比喻就能回答的问题。

9.4 已有可用API，却让系统点击网页

假设图书馆提供稳定且授权可用的查询接口，已经返回任务所需字段。此时再走“打开网页、寻找输入框、点击搜索、读页面”的路线，增加了本任务不必承担的交互环节。

但如果接口查不到所需信息，网页却在授权范围内提供，就需要重新比较，不应机械地禁止页面工具。判断标准是功能、授权、可核验性和实际表现，而不是只看入口名称。

四个反例都指向同一个问题：新增的自主步骤，到底补上了什么缺口？ 如果没有具体答案，就先不增加。

十、检查清单：先证明需要，再讨论升级

可以把这份清单用于一个真实需求。遇到“不适用”也要写明原因，不必为了全部勾选而强行增加Agent。

• [ ] 任务说清楚了。 谁使用、交什么、怎样验收、做错会怎样？
• [ ] 简单方案考虑过了。 普通程序、单次调用或固定检索能否满足要求？
• [ ] 失败原因找对了。 缺资料、缺接口、误解输入和需要动态决策，没有混为一谈。
• [ ] 动态选择确有用途。 若采用Agent，能指出哪一步依赖新的环境反馈。
• [ ] 成功不是自我声明。 客观要求有证据，主观要求有清楚的人工或分项标准。
• [ ] 权限匹配影响。 不因模型会做，就允许它执行；批准对应具体内容与对象。
• [ ] 预算包括整个任务。 查询、重试、评审和子Agent都算在内，程序负责停止。
• [ ] 失败和等待有去处。 能说明何时暂停、转人工、取消或报告未完成。
• [ ] 多Agent有比较依据。 若采用，说明分工价值，并记录相对简单基线的收益和代价。
• [ ] 决定可以回看。 ADR保留理由、限制、退回方案与重新评审条件。

知识检查

先尝试回答，再看下面的解释。重点不是背名称，而是能说明“为什么这个任务需要这一步”。

1. 老师给了一份完整通知，只要求改得适合家长阅读。为什么不一定需要Agent？
2. 模型不知道本学期的借阅新规，应先检查什么？
3. 工作流里有条件分支和审批等待，就算自主Agent吗？
4. 一个模型修改草稿，另一个模型说“很好”，是否已经完成事实核验？
5. 多个任务同时运行，与多Agent有什么区别？
6. 老师批准了通知正文，但模型随后更换收件范围，原批准能否直接沿用？
7. 多Agent方案答得更好但花费更多，应该怎样判断是否值得采用？

参考解释

第1题：任务主要是有界转换。 材料已经完整，先尝试一次改写，并核对是否保留事实即可。文风复杂不等于需要开放行动路径。

第2题：先检查权威资料是否存在、是否有权读取，以及是否被检索并提供给模型。 若问题只是知识缺失，RAG可能足够；增加Agent不能凭空产生校内规定。

第3题：不一定。 程序预定的分支仍是工作流，等待主要需要保存与恢复状态。是否自主，要看关键下一步由谁根据反馈决定。

第4题：没有。 评审意见要与原文、外部来源或明确规则相对照。另一个模型也可能出错，换角色不等于增加可信证据。

第5题：同时运行是一种调度方式。 多次独立的普通程序或模型调用也能并行；多Agent还涉及各自的上下文、任务或身份及其协作边界。

第6题：不能直接沿用。 批准应绑定具体内容与对象。收件范围改变后，程序要重新核对授权，必要时重新审批。

第7题：比较同一批代表任务的质量、等待、费用、失败和人工负担。 更多预算带来的改善可能值得，也可能不值得；要公开代价、检查波动，并说明为什么简单基线无法满足需求。

本章小结

同样是学校助手，统计人数可以用程序，改写通知可以用模型，查询新规可以用RAG，发送通知可以用审批工作流，开放资料调查才可能需要工具Agent。一个产品可以把这些方式组合起来，不必从头到尾都交给自主系统。

多Agent也一样：它是组织工作的选择，不是自动提高质量的开关。只有分工、信息、权限或任务规模确实提出要求，并且测试显示收益值得，才有理由采用。

记住这个顺序：先约定成功，再找最简单的方案；根据实际失败补能力，增加自主性时同步增加验证和控制。 下一章将走进运行过程，解释模型、工具、状态和执行步骤怎样真正接起来。

来源与证据

本章以原有蓝皮书第2章的最低充分自主性原则为主线，结合原始中文书稿有关工作流、评估和多Agent协作的论述进行教学展开。本章没有新增或复现实验，不提供某一种架构提升效果的实测结论；场景与ADR均为教学示例。引用固定到本次修改前的仓库版本，便于复核。

---

1. 蓝皮书ADR-003：最低充分自主性与P01模式卡。阶梯是本书的工程选型建议，不是研究已经证明的唯一最优顺序。 ↩↩↩

2. 原始中文书稿第1章“编排模式：工作流与自主”，以及本章修订前版本中的任务分类与模式矩阵。原稿进一步引用Anthropic的“Building effective agents”；本次以已核对的仓库内容为依据，不将九类任务宣称为外部统一标准。 ↩↩

3. 原始中文书稿第7章“验证器”“自动化评估方法”“LLM-as-a-Judge”及“评估结果的统计显著性”。本章采用明确验收、分项标准和同任务比较的方法，不引用其中的排行榜数字、产品性能或成本比例。 ↩↩↩

4. 原始中文书稿第10章“多Agent何时真正优于单Agent”“提议者—审核者范式”与“辩论模式”。本章保留外部证据的重要性，但不把“没有新信息就永远无收益”写成定律，也不把其他模型的同意当作独立事实证明。 ↩

5. 原始第10章的上下文分类、管理者模式与去中心化移交，以及本章修订前版本的“多Agent准入测试”。分工、身份隔离和交接要求在本章中作为待验证的设计理由，不据此宣称某种多Agent方案必然优于单Agent。 ↩↩

6. 本章修订前版本“影响等级与人工控制”及蓝皮书第9章：生产Harness。I0—I4是本书用于讨论控制强度的分级；审批、防重复执行与恢复措施是工程建议，不能替代具体组织的授权政策、法规判断或实际安全测试。 ↩