第1章 Agent 的边界：从对话助手到任务执行系统¶
场景引入¶
一个报价助手从“查资料、写草稿”变成“生成可发送报价单”时，系统边界已经发生变化。前者答错，销售通常还能人工修改；后者一旦接入合同、库存、折扣规则和审批系统，错误就可能进入真实业务流程。
一家制造企业曾把报价助手作为大模型试点。早期版本只查询历史合同、整理同类客户折扣范围并生成报价说明，正式报价仍由销售判断并走既有审批链。即使模型理解错某个历史项目，错误也停留在草稿层。
试点得到认可后，团队进一步接入真实工具，希望系统根据一句“客户本周要签，给一个有竞争力的价格”直接生成报价单。系统开始决定查哪些规则、采用哪个客户等级、是否触发审批，以及如何组织最终结果。一次实际任务中，它使用了过期促销规则，又错误参考了大客户折扣，却没有提示该报价需要区域总监确认。销售若直接转发，问题就不再只是“回答不准确”，而会变成价格承诺、流程绕过和责任不清。
图1-1：从对话助手到任务执行系统。来源：本书自绘。Alt text：左侧“对话助手”接收提问并返回答案，右侧“任务执行系统”在目标驱动下调用工具、推进多步动作并产生带业务后果的结果，箭头标出二者在决策与副作用上的分界。
Agent 的关键变化不在表达能力，而在于系统是否开始围绕目标自主选择动作、调用工具，并推进真实任务。 一旦模型输出开始影响业务状态，权限、审批、审计、失败恢复和运行证据就不再是附加能力，而是系统本身的一部分。
本章先处理这条边界。判断一个系统是否真正进入 Agent 范围，可以先问三个问题：最终决策由谁做？任务路径是否会根据中间结果动态变化？系统动作是否会产生业务副作用？知识查找优先考虑 RAG，内容起草优先考虑 Copilot，路径稳定的流程优先考虑 Workflow；只有当任务需要跨系统推进、根据反馈调整步骤，并持续承担执行责任时，Agent 才真正有必要登场。
1.1 从“会回答”到“会执行”：Agent 的任务闭环¶
本书不从产品名称定义 Agent，而是从任务闭环出发：
Agent 是围绕任务目标组织感知、决策、行动和反馈的系统闭环。
一个企业级 Agent 通常要处理五类对象：
表1-1：Agent 任务闭环的五个要素及各自回答的问题。来源：本书整理。
| 要素 | 它回答的问题 |
|---|---|
| 目标 | 这次到底要完成什么任务，以及回答问题是否足够？ |
| 上下文 | 为了完成任务，需要哪些数据、规则、文档和身份信息？ |
| 决策 | 面对当前状态，下一步最合适的动作是什么？ |
| 行动 | 应调用什么工具，会产生什么结果或副作用？ |
| 反馈 | 工具执行后的结果，是否改变后续决策？ |
这五个要素共同决定系统是否真正形成任务闭环。没有目标，系统会退回泛对话；没有可信上下文，判断会建立在错误信息上；没有决策，只能生成文本；没有行动，仍停留在建议层；没有反馈，系统无法根据执行结果纠错或继续推进。
真正区分 Agent 与普通大模型应用的，不是“有没有对话”“有没有调用工具”，而是系统是否能够在任务状态变化后继续决策和行动。 很多看起来像 Agent 的产品，本质仍是高级 Copilot：有对话、有工具、有结果，但没有持续状态、反馈链路和执行责任。
“Agent”概念迅速流行，主要来自三方面变化。第一，大模型把自然语言理解、跨域知识调用和结构化输出能力拉高，使系统有可能从“回答者”变成“任务参与者”；第二，Function Calling、结构化输出、Code Interpreter、MCP 等能力成熟后，模型不再只能“说”，也能较稳定地“做”；第三，企业用户越来越不希望在 CRM、ERP、BI、工单等系统之间来回切换，而希望直接把任务交给系统。
但技术能力提升并不会自动消除责任问题。企业真正需要判断的不是“它像不像 Agent”，而是“它已经承担了多少任务责任”。 一旦系统开始替人推进任务，就必须回答谁授权、依据什么信息、何时停止、失败后如何恢复，以及怎样回放当时的输入、工具调用和人工确认。
1.2 RAG、Copilot、Workflow 与 Agent：先分清系统边界¶
企业讨论 Agent 时，最常见的混乱来自命名。很多项目只要用了大模型就称为 Agent，也有不少固定流程系统被重新包装成 Agent。更稳妥的做法，是先看系统承担的职责。
- RAG 的核心是检索、补充上下文和回答问题，最终判断通常仍由用户完成，系统一般不直接改变业务状态。
- Copilot 负责起草、修改、补全和建议，主导权仍在人手里。
- Workflow 解决确定性流程，路径和规则预先写好，系统按固定步骤推进。
- Agent 围绕目标动态判断下一步，调用工具、接收反馈，并根据任务状态继续推进。
成熟系统往往不会四选一，而是组合使用：RAG 提供知识和证据，Copilot 让用户参与编辑，Workflow 固定高风险、强合规环节，Agent 负责那些无法提前写死、需要跨系统判断和推进的部分。
图1-2：RAG、Copilot、Workflow 与 Agent 的边界。来源：本书自绘。Alt text：四类系统沿“决策主体”和“执行确定性”两个维度排布，RAG 与 Copilot 由用户主导、偏低执行，Workflow 路径固定，Agent 在目标驱动下动态选择动作，虚线表示成熟系统常将四者组合使用。
判断时可以直接问“这件事真正难在哪里”：如果难点是知识查找，RAG 往往足够；如果是内容起草，Copilot 更容易落地；如果是流程规范，Workflow 更稳定；如果难点集中在多步判断、跨系统推进和实时调整，才值得使用 Agent。
系统名称并不重要，决策主体、流程确定性和执行责任才是边界。 把 RAG 当 Agent，会给简单项目增加不必要的 Runtime、审批和评测负担；把高风险 Agent 当普通聊天助手，则会漏掉权限、审计、人工确认和失败恢复。
1.3 什么任务值得做成 Agent：任务适配与风险分级¶
企业做 Agent 时，一个常见错误是“有了大模型和几个工具，就把所有智能需求都纳入 Agent”。更可控的方法，是先判断任务结构，再判断风险等级。
从任务结构看，可以粗分为四类：
- 查询型任务：核心是找到准确信息，如查询客户投诉记录。优先考虑检索、RAG、语义层或 BI。
- 草稿型任务：核心是快速生成可修改结果，如根据销售数据起草经营复盘。通常更适合 Copilot。
- 诊断型任务：需要组合多源信息、提出假设并逐步缩小问题范围，如分析区域毛利异常。此时 Agent 或 DataAgent 开始体现价值。
- 执行型任务：会调用工具、跨系统推进并产生副作用，如生成报价并进入审批。通常需要 Agent、Workflow、审批和审计共同承担。
任务适配度和风险等级是两件不同的事。 一个任务可能非常适合 Agent，但风险很高，因此只能在强审批条件下运行；也可能风险很低，但本质只是查询，并不需要 Agent。先判断“是否适合 Agent”，再判断“允许 Agent 自主到什么程度”，可以避免该快的场景做得过重、该谨慎的场景又过度自动化。
表1-2：任务的五级风险分级与对应的执行控制方式。来源：本书整理。
| 风险级别 | 典型动作 | 推荐控制方式 |
|---|---|---|
| 0 级只读 | 查资料、查指标、生成摘要 | 自动执行，保留证据 |
| 1 级低风险写入 | 创建草稿、生成待办、写入临时区 | 自动执行，可撤销 |
| 2 级中风险动作 | 更新工单状态、生成报价草稿、发内部通知 | 关键节点确认 |
| 3 级高风险动作 | 发客户邮件、提交财务凭证、修改主数据 | 审批 + 二次校验 |
| 4 级极高风险动作 | 付款、签约、删除关键数据 | 默认禁止自动执行 |
风险越高，系统越不能只依赖“模型自己判断”。只读任务可以自动执行但应保留证据；低风险写入要可撤销；中风险动作需要关键节点确认；高风险动作必须进入审批和二次校验；付款、签约、删除关键数据等极高风险动作，默认不应由 Agent 自动完成。
这也说明一个重要原则：Agent 的价值来自自主推进，但企业级 Agent 的成熟度并不等于自动化比例越高。 很多真正可长期运行的系统，会主动把高风险部分留给 Workflow 或人工审批。
1.4 企业级 Agent 为什么难：失败不只来自模型¶
企业级 Agent 最难的地方，不是让系统“更像人”，而是让系统清楚自己可以做什么、不能做什么，以及出错后如何被接管。真实生产问题通常可以分为五类：
表1-3：企业级 Agent 的五类失败及其常见根因。来源：本书整理。
| 失败类型 | 表现 | 常见根因 |
|---|---|---|
| 理解失败 | 忽略用户约束，目标理解跑偏 | 表达模糊、上下文不足 |
| 规划失败 | 选错工具、动作顺序错误、路径过长 | 工具描述差、决策策略粗糙 |
| 执行失败 | 参数不合法、工具超时、权限拒绝 | schema 薄弱、重试与恢复机制不足 |
| 治理失败 | 越权、未审批、无 trace、无法回放 | 平台策略缺失 |
| 产品失败 | 用户不信结果、不会使用、无法接管 | 前端与证据设计不足 |
这套分类的意义，是防止团队把所有问题都归咎于模型。换模型、调 Prompt 只能解决一部分理解和规划问题，工具契约、权限、语义层、审批、恢复机制和用户接管能力同样可能是根因。生产环境通常应先解决“能不能安全上线、能不能稳定运行”，再追求体验是否足够聪明。
“数字员工”类比为什么容易误导¶
“数字员工”“AI 同事”“虚拟专员”很容易传播，却容易让团队误以为 Agent 会像人一样天然理解语境、承担责任、知道分寸并自动补全上下文。真实系统并没有这种天然能力，它只是在给定上下文、工具、策略和模型能力下生成下一步动作。
更准确的工程视角是：Agent 是任务链中的系统组件，而不是能够独立承担组织责任的“员工”。 它可以承担部分感知、决策和执行工作，提高人的杠杆率，但责任仍由组织、流程和系统共同承担。工程上应该讨论“它在什么边界内可靠”，而不是“它像不像一个聪明员工”。
把业务语言翻译成系统语言¶
业务需求通常不会以 Runtime、Tool Registry、Policy 这样的技术语言提出。业务方更可能说：“自动帮我分析异常”“像助理一样跟进客户”“把月结材料整理出来”“看懂制度然后告诉我怎么处理”。这些都是真实需求，但还不是可落地的系统需求。
工程团队需要把它们继续拆解：异常如何定义、数据来自哪里、诊断步骤是什么；“跟进客户”到底是提醒、内部待办还是直接触达；月结材料中哪些数据必须精确、哪些内容可以人工修改；制度回答使用哪个权威版本、是否必须引用、是否可以进一步执行动作。
报价场景里的“给一个有竞争力的价格”，至少要拆成：竞争力相对谁衡量？客户等级允许多少折扣？销售本人具有什么权限？当前是否存在区域限价、促销或禁售规则？系统产出是建议、草稿还是正式报价？超过什么阈值必须审批？
很多失败项目不是模型听不懂业务，而是需求从未被转译成目标、上下文、工具、风险和验收标准。 这一步决定了后续工具权限、任务编排、人工节点和评测应该怎样设计。
1.5 从试点到生产：把边界变成可运行的规则¶
演示通常只关心一次交互：用户输入一句话，系统返回一个结果；生产环境面对的却是持续任务。经营分析之后还会进入会议、行动项和下次复盘；报价草稿之后还有审批、客户沟通、合同和履约；客服质检发现异常之后，还要进入培训、知识库修订和策略调整。
因此，企业级 Agent 进入生产后至少要补三件事：
- 保存任务状态：不仅保存最终答案，还要知道任务从哪里开始、经历哪些步骤、在哪里等待、哪些地方被人工确认。
- 让任务结果进入下游流程：行动项应进入项目管理系统，报价草稿应进入审批，异常应进入复核队列，而不是永远停在聊天记录里。
- 沉淀真实反馈：用户的修改、驳回、确认和异常处理，应成为后续评测和迭代依据。
从试点走向生产，至少还要跨过五道门槛：
表1-4：从试点到生产的五道门槛在两阶段的不同状态。来源：本书整理。
| 门槛 | 试点阶段常见状态 | 生产阶段必须具备 |
|---|---|---|
| 任务稳定性 | 少量案例跑通 | 覆盖边界样本和异常场景 |
| 上下文可信度 | 临时拼接资料 | 权威来源、版本和口径 |
| 边界控制 | 人工口头约定 | 明确风险分级和审批 |
| 结果可复核 | 只看最终答案 | 证据、过程、trace |
| 运营机制 | 项目组临时维护 | 持续反馈、评估和版本治理 |
试点最容易掩盖的是异常路径和长期运行问题。演示阶段的“任务完成”不代表生产阶段能够证明谁做了决策、谁批准了副作用、工具为什么这样调用、错误发生后如何恢复。
因此，生产系统往往需要接受“部分自动化”。报价助手可以自动查询历史案例、生成折扣建议、把报价单写入草稿区；超过折扣阈值、触达客户、提交正式审批等动作，则交给人工或既有 Workflow。把高风险动作停下来，并不是 Agent 能力不足，而是把自动化放在组织能够承担责任的位置。
上线前建议准备一份任务责任表，至少写清：输入来自哪里、工具能做什么、哪些步骤会改变业务状态、哪些结果只是建议、哪些动作需要确认、哪些异常必须停止、谁负责最终复核。同一个任务在总部、区域、渠道或不同业务流程中，权限和审批要求可能完全不同，因此 Agent 边界不能只按任务名称定义，而要落实到具体流程和角色。
1.6 边界评审与生产准入：用证据而不是术语做判断¶
边界评审最好发生在原型之前。候选需求应先被写成一条任务链：用户提出什么目标，系统读取哪些数据，可能调用哪些工具，每一步是否改变业务状态，哪些节点需要人确认，最终产物会被谁消费。如果这条链都无法写清，项目还不适合做生产承诺。
评审可以围绕三个核心输入：
- 任务目标：必须是可验收的业务结果，而不是“做一个更智能的助手”。例如“解释华东区毛利异常”比“做经营分析 Agent”更容易继续定义指标、数据范围和输出要求。
- 执行边界：明确允许做什么、禁止做什么。查询指标、生成草稿、写入审批草稿区、触达客户、提交正式单据，对应完全不同的风险控制。
- 证据要求：明确需要保留哪些引用、工具响应、Trace、策略命中和人工确认，确保结果可以复核和回放。
评审同时要做“降级判断”。若任务主要查资料，就回到 RAG；若主要写作，就用 Copilot；若路径固定，就用 Workflow。Agent 应留给那些路径会根据中间结果变化、需要跨系统推进并持续决策的任务。
读者也可以用五个问题快速自检：
- 系统是否会改变业务状态？
- 是否需要跨步骤记住中间结果？
- 是否会根据工具返回改变下一步？
- 是否需要在异常时恢复或转人工？
- 是否需要证明每个动作由谁授权、基于什么证据？
如果多数答案是否定的，项目可能暂时不需要 Agent；如果多数答案是肯定的，就应该尽早设计 Runtime、工具权限、HITL、Trace 和恢复机制，而不是把责任都压在 Prompt 上。
边界评审的目标不是给系统贴标签，而是确定它应该承担什么责任，以及企业需要提供哪些控制和证据。 最终至少应形成三类产物：任务责任表、运行证据要求和准入结论。
用反例检查边界¶
反例往往比定义更容易暴露问题。可以重点检查三类样本：
- 看起来完成了，但责任不清：例如 Agent 自动发送报告，却没有确认接收者和权限。
- 答案正确，但证据不足：例如模型给出合规建议，却无法说明引用了哪个制度版本。
- 流程顺畅，但无法审计：例如工具调用成功，但 Trace 没有保存参数、审批和输出 artifact。
一个系统只检索政策并生成摘要，通常属于 RAG；根据固定规则流转审批，通常属于 Workflow；只给建议而不执行，更接近 Copilot；能够选择工具、推进动作、处理失败并保留证据，才真正进入 Agent 范围。若系统已经改变业务状态，却没有 Policy、HITL、Trace 和恢复能力，问题不是“还缺几个功能”，而是边界设计尚未完成。
建立边界台账和复审机制¶
边界不会在第一次评审后永久不变。一个最初只生成合同摘要的 Copilot，后续可能接入合同库、风险条款库和审批草稿工具，逐渐开始影响法务流程。新增写操作、接入敏感数据、结果进入正式流程、用户范围扩大、自动化比例提高，都应该触发重新评审。
因此可以维护一份轻量边界台账，记录任务目标、用户角色、数据来源、系统动作、工具副作用、人工节点、证据要求、当前系统形态和下一次复审条件。被拒绝或被降级的需求也应保留原因：是因为固定 Workflow 已足够，还是因为 Trace、权限、评测或恢复机制尚未准备好。这样边界评审既是准入机制，也是平台成熟度的反馈入口。
让运行证据成为共同事实¶
Agent 进入生产后，运行证据要能被业务、平台、安全和合规团队共同复用。平台应把决策主体、工具副作用、审批点、执行回执和审计记录沉淀成稳定字段，并关联发布单、Trace、评测样本和事故记录。否则一次线上问题发生后，不同团队只能分别查看模型日志、业务日志和人工说明，很难判断问题来自数据、模型、工具、流程还是组织责任。
生产级 Agent 的边界最终要靠运行证据确认，而不是靠一次演示或一句“它已经是 Agent”。 对高风险路径，可以要求每次变更都留下证据包，并将失败样本纳入发布门槛：哪些问题必须阻断发布，哪些可以降级处理，哪些需要业务 owner 明确接受剩余风险。
1.7 从 Agent 边界到平台责任¶
当系统只回答问题时，很多责任可以停留在单个应用中；当系统开始拆解任务、调用工具、写入状态并持续推进，问题就会进入平台层。平台至少要回答：谁授权它执行？调用了什么工具？依据什么数据和规则？哪些动作产生了副作用？失败后如何恢复？最终由谁复核？
这些责任会映射到后续章节中的不同能力：Runtime 负责管理一次任务的状态和执行过程；Tool Registry 负责让工具可登记、可授权、可审计；HITL 负责在高风险节点停下来等待人工判断；Trace 负责保留过程并支持回放；评测、安全和合规能力则决定哪些任务可以继续扩大自动化范围。
全书可以用三条线索串起来：
- 执行线：模型如何从自然语言形成任务计划，Runtime 如何管理状态，工具如何被授权和调用，HITL 如何接住高风险动作。
- 证据线：RAG 引用、语义层口径、工具响应、Trace、Eval 和人工确认如何共同证明结果可信。
- 治理线：成本、SLO、安全、合规和组织责任如何约束 Agent 的扩张速度。
企业级 Agent 平台的本质，不是把所有任务都自动化，而是让“可执行的智能”在明确边界内运行、留下证据，并能够被接管和恢复。 因此早期平台不必一开始覆盖所有场景，更合理的起点是选择一条边界清楚、证据充分、工具副作用有限的任务链，先把目标、数据、工具、人工节点和回滚条件跑稳，再逐步扩展。
本章小结¶
Agent 不是大模型应用的总称。它是一类围绕目标组织上下文、决策、行动和反馈，并能够持续推进任务的系统。RAG、Copilot、Workflow 和 Agent 的区别，本质上来自决策主体、流程确定性和执行责任。
企业落地 Agent 时，应先判断任务是否真的需要动态决策和跨系统执行，再按业务副作用划分风险等级。进入生产后，模型能力只是其中一部分，工具契约、权限、审批、任务状态、Trace、失败恢复和人工接管同样决定系统能否长期运行。
判断一个 Agent 是否成熟，不应只看它能完成多少动作，而应看它是否知道哪些动作可以自动完成、哪些必须停下来，以及每一次执行能否被证明、复盘和恢复。 下一章将继续讨论平台边界：企业真正需要建设的不是一组彼此孤立的 Agent，而是一套能够复用模型、工具、运行、评测、安全和审计能力的共享基础设施。
参考文献¶
Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR.
Schick, T. et al. (2023). Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS.
Russell, S. & Norvig, P. (2020). Artificial Intelligence: A Modern Approach. Pearson.
OpenAI. (n.d.). Function calling guide.