第1章 Agent 的边界：从对话助手到任务执行系统¶
场景引入¶
一个报价助手从“查资料、写草稿”变成“生成可发送报价单”时，系统边界已经变了。前者答错，销售通常还能人工改；后者一旦调用了折扣规则、库存系统和审批接口，错误就会进入真实业务流程。很多企业第一次做 Agent，都会在这里误判：演示里的对话很顺，任务看起来也完成了，但系统是否已经在替人做决策、是否产生副作用、是否需要审批和审计，并没有被同步设计。图 1-1 要说明的就是这条分界线：系统从给出建议转向推进任务时，工程责任也随之改变。
一家制造企业曾经把报价助手作为大模型试点。早期版本只做三件事：查询历史合同，整理同类客户的折扣范围，帮销售写一版报价说明。这个版本看起来不够“自动”，但风险很清楚。系统给出建议，销售判断是否采用，正式报价仍然走原来的审批链。即使模型把某个历史项目理解错了，错误也停留在草稿层，销售和主管还有机会发现。
试点得到认可后，业务团队希望把流程再往前推一步。销售不想在合同系统、库存系统、折扣规则和邮件系统之间来回切换，于是团队把这些工具接给模型，让它根据一句“客户本周要签，给一个有竞争力的价格”直接生成报价单。表面上看，用户体验只是少了几次点击；系统责任却完全不同。模型开始决定查哪些规则、套用哪个客户等级、是否触发审批，以及把结果以什么格式交给销售。销售看到的不再是一段可修改建议，而是一份可以被转发给客户的业务文件。
真正的问题往往发生在这种灰色地带。系统没有主动发邮件，也没有自动签合同，所以团队容易认为风险还在可控范围内。但它已经把过期促销规则写进了报价草稿，又把“有竞争力”理解成向大客户折扣靠拢，最后还没有提醒销售这份折扣必须先经过区域总监确认。销售如果在忙乱中直接复制发送，后果就不再是“回答不准确”，而是价格承诺、审批绕过和客户预期管理的问题。这类事故很少能靠一句“模型要更准”解决。模型确实需要更准确，但系统还需要知道哪些数据是权威版本，哪些动作只是建议，哪些动作会改变业务状态，谁有权确认，出了问题以后怎样回放当时的输入、工具调用和中间判断。企业讨论 Agent 的第一步，应该先把这些责任摊开，而非急着给所有智能功能贴上同一个名字。
图1-1：从对话助手到任务执行系统。来源：本书自绘。Alt text：左侧“对话助手”接收提问并返回答案，右侧“任务执行系统”在目标驱动下调用工具、推进多步动作并产生带业务后果的结果，箭头标出二者在决策与副作用上的分界。
Agent 的关键变化不在表达能力，而在任务推进方式：它开始把数据、工具、流程和责任边界组织到同一条任务链中。本书讨论的 Agent，是企业系统里被约束、被观察、可回放、可降级的一类任务执行能力。读者不应把演示视频里的“自动完成一切”当成建设目标，而应关心系统进入真实流程后承担了哪些责任。本书会区分智能交互、任务执行和平台责任，避免把所有能力都装进同一个概念里。后续每一章都会回到同一个问题：当模型输出开始影响真实业务动作时，系统需要补上哪些工程责任。
本章先处理概念边界。读完这一章，读者应能用三个朴素问题判断一个系统是否进入 Agent 范围：最终决策由谁做，任务路径是否会动态变化，系统动作是否会产生业务副作用。知识查找问题优先考虑 RAG，内容起草问题优先考虑 Copilot，路径稳定的问题优先考虑 Workflow。只有当任务需要跨系统推进、根据反馈调整步骤，并且每一步都可能改变后续选择时，Agent 才真正有必要登场。这种判断的目的在于减少上线时的错配，技术标签只是辅助。把 RAG 当 Agent，会让项目背上不必要的审批和运行时负担；把 Agent 当聊天助手，又会漏掉权限、审计、失败恢复和人工确认。企业级 Agent 的设计从边界开始，本章讨论的每个概念，后面都会落到具体平台组件上。
1.1 从“会回答”到“会执行”：Agent 的根本转折¶
一家多业务线企业的制造板块曾经做过一个报价助手。最初它只是帮助销售查询历史合同、参考折扣区间、生成报价草稿。演示时效果很好：用户提出需求，系统几秒钟内给出一份结构化报价建议，还能整理过去类似项目的参考案例。团队很快产生了一个自然但危险的判断：既然它已经能“看懂问题、找到信息、写出结果”，那不如再往前走一步，让它直接帮销售完成报价动作。于是报价助手被接上真实工具：合同系统、库存系统、折扣策略、审批接口，甚至还可以自动生成对客户的报价邮件草稿。问题很快暴露出来。有一次，一位销售输入：“客户希望这周签约，给一个尽量有竞争力的价格。”系统按照历史案例推断出 12% 的折扣方案，并生成了报价单。表面上，这只是“把建议变成草稿”；实际链路已经变成企业任务：理解意图、判断价格策略、调用工具、产出带业务后果的结果。
事后复盘发现三处问题。第一，系统调用了过期的促销规则，没有意识到当天生效的新限价。第二，它默认把“尽量有竞争力”理解为“向历史大客户靠拢”，却忽略了这个客户并不具备同等级折扣权限。第三，它把本应进入审批链的结果提前送到了销售手里，用户稍不留神就可能转发给客户。这个案例揭示了一个经常被低估的转折点：系统一旦开始替人推进任务，讨论对象就会从问答质量转向执行责任。问答系统出错，常常只是答案不好；执行系统出错，可能意味着权限越界、流程绕过、数据误用、责任不清。按照这个边界看，Agent 应被当成任务执行系统处理，而非被当成更聪明的聊天助手。后续章节讨论 Runtime、工具注册、HITL、Trace 和评测时，也都会沿着这条责任边界展开。
1.2 RAG、Copilot、Workflow、Agent：四类系统的边界¶
企业讨论 Agent 时，最大的混乱之一来自命名。很多项目只要用了大模型，就自称 Agent；很多固定流程系统，也被包装成 Agent。后续章节要讨论平台、工具和治理，先需要把四类常见形态分开。RAG 的核心工作是找资料、给答案和补上下文，最终决策仍由用户完成，系统通常不直接推进业务状态。Copilot 更进一步，它会陪用户起草、修改、补全和建议，但主导权仍在人手里。Workflow 解决的是确定性流程，把规则和路径预先写好，系统按既定步骤推进。Agent 则不同，它围绕目标动态判断下一步，调用工具、接收反馈，并在任务状态变化后继续推进。这四类经常组合出现。一个成熟系统可能用 RAG 提供知识与上下文，用 Copilot 帮用户起草或修改结果，用 Workflow 固定高风险、强合规的环节，再把无法提前写死、需要跨系统推进的部分交给 Agent。
判断重点不在名字，而在系统承担的职责。系统如果主要在企业知识库里找答案，大概率是 RAG；始终由人主导，模型只是在旁边给建议，更像 Copilot；从第一步到收尾路径都固定，则更接近 Workflow。系统围绕目标理解上下文、选择动作、接收反馈并继续推进时，才进入本书所说的 Agent 范围。更实用的问法是：“这件事的难点在哪里？”如果困难主要在知识查找，RAG 往往已经够用；如果困难在内容起草，Copilot 更容易落地；如果困难在流程规范，Workflow 的稳定性更高；只有当困难集中在多步判断、跨系统推进和实时调整上，才值得把它作为 Agent 任务处理。
图1-2：RAG、Copilot、Workflow 与 Agent 的边界。来源：本书自绘。Alt text：四类系统沿“决策主体”和“执行确定性”两个维度排布，RAG 与 Copilot 由用户主导、偏低执行，Workflow 路径固定，Agent 在目标驱动下动态选择动作，虚线表示成熟系统常将四者组合使用。
图 1-2 提醒团队先看责任边界，再谈系统名称。成熟系统可以组合 RAG、Copilot、Workflow 和 Agent，但组合方式必须服从决策主体、流程确定性和执行责任这三个约束；只要某个环节开始替用户推进业务动作，就要按 Agent 的工程责任处理。
1.3 Agent 的任务闭环：目标、上下文、决策、行动与反馈¶
本节把 Agent 放回任务回路里定义，而非从模型能力或产品名称出发。这样做的好处是，后续讨论工具、记忆、审批和评测时，都能回到同一个问题：系统是否真的围绕任务持续推进。用一句尽可能朴素的话说：
Agent 是围绕任务目标组织感知、决策、行动和反馈的系统闭环。
这个定义的重心在“闭环”。一个企业级 Agent 通常要处理五类对象；表 1-1 将它们拆成五个问题，便于后续映射到 Runtime、Planner、工具调用和 Trace。
表1-1：Agent 任务闭环的五个要素及各自回答的问题。来源：本书整理。
| 要素 | 它回答的问题 |
|---|---|
| 目标 | 这次到底要完成什么任务，以及回答问题是否足够？ |
| 上下文 | 为了完成这个任务，需要哪些数据、规则、文档和身份信息？ |
| 决策 | 面对当前状态，下一步最合适的动作是什么？ |
| 行动 | 应该调用什么工具，产生什么结果或副作用？ |
| 反馈 | 工具执行后的结果，是否改变了后续决策？ |
这些环节少掉任何一个，系统都会退回到更弱的形态。没有目标，它会变成泛对话；没有上下文，它会在错误信息上做看似合理的判断；没有决策，它只能生成文字；没有行动，它停留在建议层；没有反馈，它很难纠错，也难以收敛。很多“看起来像 Agent”的产品更接近高级 Copilot：有对话、有工具、有结果，但任务没有形成反馈链路。对企业来说，闭环还会带来责任问题：谁允许系统这么做，它依据什么信息判断，什么条件下要停下，做错以后怎样发现、复盘和修正。这些问题无法靠单个应用自行消化，最终都会回到平台层。
1.3.1 Agent 概念快速泛化的原因¶
“Agent”这个词的快速流行，既来自学术定义，也来自几股力量叠加。模型能力先发生了变化。过去的企业 AI 系统大多擅长分类、预测、检索和生成某个局部结果，很少让系统自己决定“下一步做什么”。大模型把自然语言理解、跨域知识调用和结构化输出能力拉高之后，企业开始看到一种可能性：系统可以从回答者变成任务参与者。工具调用能力也在成熟。早期大模型应用即使回答质量不错，也常常停留在文本世界里。Function Calling、结构化输出、Code Interpreter、MCP 这类能力逐渐成熟之后，模型不再只是“说”，也能比较稳定地“做”。这使企业需要认真面对执行边界。
企业软件形态本身也在变化。过去十几年，企业软件的主导范式是模块化 SaaS：CRM 是一个系统，ERP 是一个系统，BI 是一个系统，工单又是一个系统。大模型出现之后，用户更明确地提出一种期待：不想在系统之间来回切换，只想把任务交给系统。热度来得太快，“Agent”也就容易被拿来包装任何大模型功能。判断一个系统是否真的进入 Agent 范畴，还是要回到它承担了多少任务责任。
1.4 Agent 适配任务的场景分型、风险分级与价值判断¶
企业做 Agent 时，常见问题是边界铺得太泛。很多团队一旦有了大模型和几个工具，就把所有智能需求都归到 Agent 下面，治理压力也随之放大。更可控的方式，是先给企业任务分型。查询型任务的难点在于找到准确信息，优先使用检索、RAG、语义层或 BI；草稿型任务的难点在于快速生成可修改结果，更适合 Copilot 或内容生成助手；诊断型任务需要组合多源信息并逐步缩小问题范围，才开始显出 Agent 的价值；执行型任务会调用工具、跨系统推进并产生副作用，通常需要 Agent、Workflow 和审批链共同承担。
放到具体场景里，这个判断会更清楚。“查一下某客户近三个月投诉记录”首先是查询型任务，RAG 加 CRM 查询就能覆盖大部分价值；“根据这周销售数据起草经营复盘”主要是草稿型任务，Copilot 或低风险任务型 Agent 就够用；“解释华东区毛利率为什么异常”需要跨指标、订单、库存和历史解释逐步诊断，更接近 DataAgent；“生成报价并进入审批”已经触达业务动作，必须把 Agent 和 Workflow、审批、审计放在一起设计。这套分类法有两个用处：避免过度设计，也帮助团队判断哪些场景会拉动平台能力。诊断型和执行型任务，通常会稳定需要 Runtime、Registry、Policy、Trace。任务适配度和风险等级是两张不同的表。一个任务可能非常适合 Agent，但风险等级很高，因此只能在强审批前提下推进；也可能风险不高，但其实根本不需要 Agent。企业经常把这两件事混为一谈，于是该快的场景做得很慢，该谨慎的场景又做得太冒进。
表1-2：任务的五级风险分级与对应的执行控制方式。来源：本书整理。
| 风险级别 | 典型动作 | 推荐控制方式 |
|---|---|---|
| 0 级只读 | 查资料、查指标、生成摘要 | 自动执行，保留证据 |
| 1 级低风险写入 | 创建草稿、生成待办、写入临时区 | 自动执行，可撤销 |
| 2 级中风险动作 | 更新工单状态、生成报价草稿、发内部通知 | 关键节点确认 |
| 3 级高风险动作 | 发客户邮件、提交财务凭证、修改主数据 | 审批 + 二次校验 |
| 4 级极高风险动作 | 付款、签约、删除关键数据 | 默认禁止自动执行 |
更可控的做法，是先判断“这个任务结构上是否适合 Agent”，再判断“即使适合，它允许 Agent 自主到什么程度”。本书把 Agent 的定义、平台边界和 AI 原生系统分成三章来讲，原因也在这里：任务适配、治理约束和系统形态属于不同层次。
1.5 企业级 Agent 的难点：边界、责任与组织语言¶
消费级 Agent 最吸引人的地方，是它看起来什么都能做；企业级 Agent 最难的地方，是它要清楚自己停在哪里。一旦放进企业环境，Agent 面对的是组织边界、权限边界、流程边界和责任边界。也因此，企业级 Agent 的困难通常不先出现在“模型会不会回答”，而会出现在下面五类失败上。
表1-3：企业级 Agent 的五类失败及其常见根因。来源：本书整理。
| 失败类型 | 表现 | 常见根因 |
|---|---|---|
| 理解失败 | 忽略用户约束，目标理解跑偏 | 表达模糊、上下文不足 |
| 规划失败 | 选错工具、动作顺序错误、路径过长 | 工具描述差、决策策略粗糙 |
| 执行失败 | 参数不合法、工具超时、权限拒绝 | schema 薄弱、重试与恢复机制不足 |
| 治理失败 | 越权、未审批、无 trace、无法回放 | 平台策略缺失 |
| 产品失败 | 用户不信结果、不会使用、无法接管 | 前端与证据设计不足 |
这套失败谱系有一个重要作用：防止团队把一切问题都归咎于模型。很多企业项目一出错，第一反应是“换模型”或者“继续调 Prompt”。但问题也可能来自工具契约、权限、语义层或审批链。把问题分类，是在恢复系统分析能力。在企业里，失败处理有优先级。治理失败决定能否上线，执行失败决定系统是否稳定，理解与规划失败决定结果质量，产品失败决定用户能否长期使用。企业场景先看可控，再看体验是否足够出彩。
1.5.1 “数字员工”类比的局限¶
市场宣传里很喜欢把 Agent 称为“数字员工”“AI 同事”“虚拟专员”。这些说法容易传播，但在工程上很危险。因为一旦把 Agent 想象成“员工”，团队就很容易期待它像人一样理解语境、承担责任、知道分寸、自动补全上下文。但真实系统并不会天然拥有这些能力。它只是在给定上下文、工具、策略和模型能力下生成下一步动作。更准确的说法是：Agent 是任务链中的系统组件，承担部分感知、决策和执行工作。它可以提高人的杠杆率，企业责任链仍然由组织、流程和系统共同承担。把 Agent 当成员工，讨论会滑向“它够不够聪明”；把 Agent 当成任务执行系统，讨论会回到“它在什么边界内可靠”。企业要回答的是后一个问题。
1.5.2 从业务语言到系统语言¶
企业里提出 Agent 需求的人，往往是业务负责人、产品经理、运营团队或职能部门，而非工程师。他们不会说“我需要一个带 Runtime、Tool Registry 和 Policy 的任务执行系统”，他们通常会说：“希望系统自动帮我分析异常”“希望它像助理一样跟进客户”“希望它把月结材料先整理出来”。这些表达都是真实需求，但还不是系统需求。Agent 平台工程师首先要把业务语言翻译成系统语言。这种翻译过程看似是需求澄清，实际决定项目能否落地。业务方说“自动帮我分析异常”时，系统要追问异常定义、数据来源和诊断步骤；业务方说“像助理一样跟进客户”时，系统要区分提醒、内部待办、客户触达和审批责任；业务方说“把月结材料整理出来”时，系统要区分必须准确的数据、可以人工修改的草稿和需要审计的结论；业务方说“看懂制度然后告诉我怎么处理”时，系统要确认制度来源是否权威、答案是否需要引用、是否能形成具体动作。
很多失败项目的根因不在模型能力，而在需求没有被拆成目标、上下文、工具、风险和验收标准。以报价助手为例，“给一个有竞争力的价格”在业务语言里很自然，但在系统语言里至少要拆成五个问题：有竞争力是相对历史同类客户，还是相对当前库存压力？客户等级和销售权限允许的折扣上限是多少？当前是否存在区域限价、活动政策或临时禁售规则？系统生成的是建议、草稿，还是可以直接进入报价流程？超出什么阈值必须进入审批？只有完成这种翻译，Agent 才能从“会听懂人话”走向“能在企业边界内做事”。
1.6 从试点到生产：生命周期、任务组合与运营门槛¶
很多企业在早期设计 Agent 时，会把注意力放在一次交互上：用户输入一句话，系统输出一个结果。这个视角适合演示，却不足以理解企业级 Agent。企业里有价值的任务，往往是一段持续过程，而非一次问答。经营分析问出“毛利为什么下降”之后，还会进入会议、行动项、责任人和下周复盘。报价生成草稿之后，还要进入审批、客户沟通、合同签署和履约跟踪。客服质检发现异常之后，还要进入人员培训、知识库修订和服务策略调整。Agent 一旦进入企业，就会从“一次执行”变成“长期运行”。随之而来的是几项基本要求。
任务状态需要被保存。系统除了最终答案，还要知道任务从哪里开始、经历了哪些步骤、哪些地方被人确认过、哪些地方还在等待。任务结果需要能被后续消费。经营分析 Agent 生成的行动项，可能要进入项目管理或会议系统；报价 Agent 生成的草稿，可能要进入审批系统；票据 Agent 发现的异常，可能要进入财务复核队列。Agent 的结果如果只是聊天记录，就很难成为企业工作的一部分。任务经验也要能沉淀。用户每一次修改、驳回、确认和反馈，都是系统改进的依据。企业级 Agent 上线后，仍要通过持续反馈贴近企业真实工作方式。
1.6.1 试点到生产的五道门槛¶
很多 Agent 项目并非卡在试点，而是试点成功后过早进入生产。从试点到生产，至少有五道门槛。
表1-4：从试点到生产的五道门槛在两阶段的不同状态。来源：本书整理。
| 门槛 | 试点阶段常见状态 | 生产阶段必须具备 |
|---|---|---|
| 任务稳定性 | 少量案例跑通 | 覆盖边界样本和异常场景 |
| 上下文可信度 | 临时拼接资料 | 权威来源、版本和口径 |
| 边界控制 | 人工口头约定 | 明确风险分级和审批 |
| 结果可复核 | 只看最终答案 | 证据、过程、trace |
| 运营机制 | 项目组临时维护 | 持续反馈、评估和版本治理 |
这五道门槛属于 Agent 系统本身，是上线前要处理的工程责任。Agent 的价值来自执行；进入执行之后，稳定性、可信度、控制边界、复核能力和运营机制都要跟上。还有一个常被忽略的门槛，是业务团队是否已经接受“部分自动化”的现实。很多试点在演示时追求一口气完成任务，生产时却需要把动作拆成可自动执行、需要确认、必须审批和默认禁止几类。报价助手可以自动整理历史案例，可以生成折扣建议，也可以把报价单写入草稿区；但超过折扣阈值、触达客户邮件、提交正式审批这些动作，应由人或既有流程接住。这样的拆分看起来降低了自动化程度，实际是在保护系统能长期运行。
从这个角度看，Agent 上线前最该准备的不是一段更长的 Prompt。团队更需要一份任务责任表。表里要写清楚输入来自哪里，工具能做什么，哪些步骤会改变业务状态，哪些结果只作为建议，哪些异常必须停下。工程团队用它设计工具权限和 Runtime，业务团队用它确认流程责任，安全和内控用它判断审批要求。没有这份责任表，系统即使能跑通，也很难进入生产。责任表还会暴露一个现实：同一个任务在不同组织里边界不同。总部报价、区域报价和渠道报价可能使用不同折扣权限；内部经营复盘和对外客户邮件也对应不同审批要求。Agent 设计如果只看任务名称，就会忽略折扣权限、审批要求和对外承诺这类流程差异。真正要判断的是它进入哪条业务流程。一旦企业开始认真面对这些门槛，它就不可能只做一个孤立 Agent，而必然要进入平台问题。这正是第二章的起点。
1.7 企业 Agent 边界的评审方法¶
边界评审最好发生在原型之前，而不是演示之后。原型阶段一旦把工具、数据和界面都接起来，团队很容易被“已经能跑通”牵着走，反而不愿意重新拆任务责任。更稳妥的做法，是把候选 Agent 需求先写成一条任务链：用户提出什么目标，系统需要读取哪些数据，可能调用哪些工具，每一步是否改变业务状态，哪些节点需要人确认，最终产物会被谁使用。只要这条链写不完整，就说明项目还停留在想法层，不能直接进入生产承诺。
评审时可以先看三个输入。第一是任务目标，必须写成可验收的业务结果，而不是“让系统更智能”。“解释华东区毛利异常”比“做一个经营分析助手”更适合评审，因为前者能继续追问指标口径、数据范围、异常定义和输出格式。第二是执行边界，必须列出系统允许做的动作和默认禁止的动作。查询指标、整理历史案例、生成草稿、写入审批草稿区、触达客户、提交正式单据，对应完全不同的风险控制。第三是证据要求，必须说明结果需要哪些引用、Trace、工具响应和人工确认记录。没有证据要求的 Agent，即使短期体验很好，也很难在事故和复盘中站得住。
边界评审还要做降级判断。并不是每个候选需求都应该被做成 Agent。若任务主要是查资料，RAG 加引用和权限过滤可能更合适；若任务主要是写文案或整理材料，Copilot 形态通常更容易被用户接管；若流程路径稳定，Workflow 的确定性和审计性更可靠。Agent 适合那些路径会随中间结果变化、需要跨系统推进、并且需要在执行中持续判断的任务。把简单查询做成 Agent，会增加运行时、审批和评测负担；把高风险执行伪装成 Copilot，则会漏掉工具权限、人工确认和失败恢复。
评审结果应形成三类产物。第一类是任务责任表，记录目标、参与角色、工具、数据、风险等级和人工节点。第二类是运行证据要求，说明 Trace 至少要记录哪些输入、输出、工具调用、策略命中和人工操作。第三类是准入结论，明确当前需求适合 RAG、Copilot、Workflow、Agent，还是只适合继续做探索原型。这样的结论看起来比“做一个智能助手”更慢，却能减少后续返工。企业级 Agent 的可靠性要从边界评审开始，把责任写进系统设计；上线后的运营只能修正问题，无法替代前期边界设计。
1.8 从概念边界到平台责任¶
本章讨论 Agent 的边界，是为了明确企业系统要承担哪些新责任，而不是给行业术语下一个固定定义。一个系统一旦从“回答问题”走向“拆解任务、调用工具、推进状态”，它就不再只是模型应用。平台必须能回答：谁授权它执行，执行了哪些动作，依据哪些证据，失败后如何恢复，结果由谁复核。读者在后续章节中会反复看到这个边界。第22章的 Runtime 负责把任务变成可管理的 Run，第23章的 Tool Registry 负责让动作可登记和可审计，第30章的 HITL 负责让高风险动作停下来等人判断，第38章的 Trace 负责让过程可回放。没有这些平台责任，Agent 很容易停留在演示阶段：它能生成一个合理答案，却无法成为企业生产系统。判断一个场景是否适合 Agent 时，模型能不能理解用户意图只是起点。团队还要看任务是否需要跨步骤推进，是否会触达企业数据和工具，是否需要证据链和责任链。这个判断会直接影响全书的阅读方式：前几章建立平台观，后续章节逐层补齐模型、数据、工具、运行时、评测、安全和组织治理。
1.9 读者预期与章节主线¶
本章给出的边界判断，会贯穿后续所有章节。读者不必把 Agent 当作一个更聪明的聊天界面来理解，而应把它看成会进入企业任务链的运行系统。只要系统开始拆解目标、选择工具、读取数据、写入状态或生成可交付产物，它就需要平台来管理授权、执行、证据和回滚。后续章节讨论模型、知识库、工具、Runtime、DataAgent、Trace、安全和组织治理时，都会回到同一个问题：这次自动化到底改变了哪一个业务状态，谁允许它改变，系统留下了什么证据。
阅读本书时，可以先用三条线索串起内容。第一条线索是执行线：模型如何从自然语言变成任务计划，Runtime 如何管理中间状态，工具如何被登记、授权和调用，HITL 如何接住高风险动作。第二条线索是证据线：RAG 引用、语义层口径、工具响应、Trace、Eval 和人工确认如何共同说明一次结果可信。第三条线索是治理线：成本、SLO、安全、合规、组织责任和案例准入如何限制 Agent 的扩张速度。这三条线索共同决定 Agent 能否从演示进入生产。
初学者容易把 Agent 的难点理解成“模型还不够强”。模型能力当然重要，但企业落地的主要矛盾往往出现在模型之外：上下文来源不稳定，工具契约不清，权限没有透传，审批状态无法恢复，Trace 不能回放，错误样本没有进入评测。把这些问题提前说清，是为了让读者在后续章节中看到各个技术模块的真实位置。比如第8章的结构化输出承担工具执行前的契约职责；第23章的 Tool Registry 汇集权限、schema 和审计入口；第38章的 Trace 支撑事故定位和评测回放。
因此，早期平台不需要一开始覆盖所有场景。更合理的起点，是选一条边界清楚、证据充分、工具副作用有限的任务链，把目标、数据、工具、人工节点和回滚条件写成可审查材料。平台先把这条链跑稳，再逐步扩展到更多业务域。这样读者在后续章节看到复杂架构时，不会把它理解成一次性建设的大工程，而会理解成企业 Agent 在生产中被迫补齐的一组能力。
1.10 边界评审样本与读者自检¶
读者可以用一组样本来检验本章边界。第一个样本是知识问答：用户问制度条款，系统检索文档、给出引用、不产生外部动作。这通常更接近 RAG。第二个样本是写作辅助：用户要求生成会议纪要或邮件草稿，系统输出可编辑文本，由人决定是否发送。这更接近 Copilot。第三个样本是固定审批流：用户提交报销材料，系统按确定规则校验、流转、归档。这更接近 Workflow。第四个样本是经营异常分析：系统要澄清指标、查数、分析原因、生成图表、等待负责人确认，并把结论带入下次复盘。这才更接近 Agent。
这组样本的用途，是帮助团队把需求放到正确形态里。若团队把所有样本都叫 Agent，后续就会为简单任务引入过重运行时，也会为高风险任务遗漏审批和 Trace。边界评审服务于责任分配，让不同系统形态承担合适责任。RAG 要做好证据和权限，Copilot 要做好可编辑和接管，Workflow 要做好确定性和审计，Agent 要做好状态、工具、恢复和责任链。
读者自检时可以问五个问题。系统是否会改变业务状态？是否需要跨步骤记住中间结果？是否会根据工具返回改变下一步？是否需要在异常时恢复或转人工？是否需要证明每个动作由谁授权、基于什么证据？如果多数答案是否定的，项目可能暂时不需要 Agent 形态；如果多数答案是肯定的，就应尽早引入平台能力，而不是把所有责任压到 Prompt 上。
这个自检会影响后续阅读。把项目判定为 RAG，就优先读第19章到第21章和第40章；判定为工具增强 Copilot，就优先读第8章、第23章和第47章；判定为长任务 Agent，就要读 Runtime、Planner、Memory、HITL、Trace 和安全章节。第一章给出入口判断，后续章节负责把这些判断落成工程实现。
1.11 边界判断对后续章节的约束¶
本章的边界判断会约束后续章节的阅读方式。读模型章节时，读者要同时关注推理服务的回答质量和任务执行支撑能力；读工具章节时，要关注工具调用是否改变业务状态，以及状态变化是否留下证据；读 Memory、Planner 和 Runtime 章节时，要关注系统是否拥有跨步骤决策能力，以及这种能力是否受到权限、预算和审批限制；读 DataAgent、观测、评测和安全章节时，要关注 Agent 行动之后是否能被复盘、评估和恢复。Agent 是多项平台能力组合后的运行形态，跨越模型、工具、运行时、证据和治理边界。
这种约束能帮助读者避免两类误读。第一类误读是把所有对话式体验都理解为 Agent，于是过早引入 Planner、Memory 和多工具编排，结果增加了成本和风险；第二类误读是把 Agent 只理解为模型推理，于是忽视工具权限、审批、Trace、Eval 和安全门禁，系统上线后无法承担真实业务责任。全书采用平台视角，是因为企业场景里的问题通常不会停在单一模型或单一应用。一个任务能否进入 Agent 化改造，要同时看决策主体、动作副作用、失败恢复、证据保留和组织责任。
因此，第一章提供的是后续工程判断的入口。读者可以在每一章反复回到本章的问题：这个能力是否让系统更接近可执行任务，是否带来新的责任边界，是否需要平台治理承接。如果答案清楚，扩展功能才有意义；如果答案模糊，就应先补边界、证据和恢复路径，再谈更复杂的 Agent 能力。
1.12 术语边界的团队对齐¶
Agent、Copilot、Workflow、RAG 这些词在企业内部很容易被不同团队用成不同含义。产品团队可能把任何对话入口叫 Agent，模型团队可能把工具调用叫 Agent，业务团队可能把自动化流程叫 Agent，安全团队关心的是系统是否产生副作用。术语没有对齐时，评审会就会变成概念争论，真正需要决定的权限、证据和恢复路径反而被推迟。
团队对齐可以从任务样本开始。先把任务拆开：用户提出什么目标，系统读取哪些上下文，是否调用工具，是否改变业务状态，是否需要人工确认，失败后如何恢复。样本拆清后，系统形态自然会显现。术语应服务工程判断，工程判断不应被术语标签牵着走。
本书后续章节也采用这种方式。每次引入能力，都尽量说明它解决哪一段任务链路、承担什么责任、留下什么证据。读者如果在自己的团队里使用本书，可以先用第1章的边界样本做内部校准，再进入具体技术选型。术语一致后，平台建设会少很多无效争论。
1.13 边界判断的验收证据¶
Agent 边界判断需要验收证据。团队不能只说某个系统“已经是 Agent”，而要能展示目标、上下文、决策、行动、反馈和责任记录。若系统只能回答问题，没有可审计动作，就应归入 RAG 或 Copilot；若系统能发起工具调用，但缺少审批、回滚和 Trace，就还没有进入企业级生产边界。
验收时可以抽取几条真实任务链，检查用户意图如何转成计划，工具调用如何被授权，失败如何恢复，人工如何确认，最终产物如何进入下游流程。这样的证据会让概念边界服务工程判断，也为后续平台章节建立共同语言。
1.14 边界评审台账与后续追踪¶
边界评审不能只停留在一次会议结论。企业里同一个 Agent 需求会经历原型、灰度、上线、扩展和下线，边界也会随着工具接入、数据范围扩大、用户群变化而移动。第一章给出的 RAG、Copilot、Workflow、Agent 分类，应进入一份轻量台账，记录需求最初为什么被归到某一类、哪些证据支持这个判断、哪些条件变化后需要重新评审。台账不需要复杂系统，一张结构化记录就足够：任务目标、用户角色、系统动作、数据来源、工具副作用、人工节点、证据要求、当前形态、下一次复审时间。
这份台账能解决一个常见问题：原型阶段被判定为 Copilot 的能力，后续逐渐接入工具、审批和自动写入，却没有重新进入 Agent 评审。比如一个合同摘要助手最初只生成可编辑草稿，风险很低；几个月后它接入合同库、风险条款库和审批草稿工具，开始影响法务工作流。若团队仍按 Copilot 管理，就会缺少 Tool Registry、HITL、Trace 和权限复核。台账中的触发条件可以提醒团队重新分类：新增写操作、接入敏感数据、结果进入正式流程、用户范围扩大、自动化比例上升，都应触发边界复审。
边界台账还应保留被拒绝和被降级的需求。一个需求没有进入 Agent 形态，可能是因为任务路径稳定，适合 Workflow；也可能是因为证据不足，只能先做 RAG 或 Copilot。把这些结论留下来，后续业务再次提出同类需求时，团队能看到之前的判断依据和缺口，而不是重新争论术语。被降级的需求也会反向推动平台建设：缺 Trace，就补运行记录；缺权限模型，就补策略；缺评测样本，就补质量门禁。这样边界评审不会变成阻拦创新的流程，而会变成平台成熟度的反馈入口。
台账还要和后续章节衔接。第22章的 Runtime 可以读取任务形态决定状态机复杂度；第23章的 Registry 可以根据风险等级设置工具准入；第30章的 HITL 可以根据人工节点定义审批语义；第38章的 Trace 可以按证据要求决定记录粒度；第50章和第51章可以根据数据和动作边界设置安全样本。第一章的概念边界一旦进入台账，就能转成后续章节的工程输入。读者在自己的项目里也可以用同样方法：先记录边界，再根据边界决定需要哪些平台能力。
1.15 边界判断的反例复盘¶
理解 Agent 边界时，反例比定义更有用。很多项目失败并非模型回答能力不足，而是团队把普通自动化、检索问答或流程编排包装成 Agent，又没有补齐行动责任、状态恢复和审计证据。演示阶段看起来顺畅，生产阶段却会在写操作、审批、权限和异常路径上暴露缺口。第1章需要提醒读者：判断一个系统是不是 Agent，不能只看界面是不是对话式，也不能只看是否调用了模型。
反例复盘可以从任务后果开始。一个系统只检索政策并生成摘要，通常属于知识问答；一个系统根据固定规则流转审批，通常属于 Workflow；一个系统能解释下一步建议，但不会自动执行，可能是 Copilot；一个系统能选择工具、发起动作、处理失败并保留证据，才进入 Agent 边界。若系统会改变业务状态，却没有 Runtime、Policy、HITL 和 Trace，就属于边界设计不足，而不是“还缺几个功能”。
反例还可以帮助团队收敛范围。早期项目可以先停在 Copilot 或 Workflow 形态，不必强行升级为 Agent。对于风险高、证据不足、责任不清的任务，先让系统给建议和草稿，人工确认后再执行；等工具契约、权限、评测和恢复链路稳定后，再扩大自动化范围。这个节奏能减少试点失败，也能让平台建设有明确顺序。
早期可以要求每个 Agent 立项都写一段反例说明：为什么它不是普通 RAG，为什么固定 Workflow 不够，哪些动作需要模型参与决策，哪些动作必须人工确认。反例说明会迫使团队把边界讲清楚，也为后续章节的 Runtime、Tool Registry、HITL 和 Trace 铺好入口。
1.16 Agent 边界的反例复盘¶
理解 Agent 边界，最有效的方式之一是复盘反例。很多团队第一次做 Agent，会把一次顺畅演示当成能力成立：用户提问，模型调用工具，页面返回结果。真正上线后，问题往往出在演示没有覆盖的地方。模型是否替用户做了不可逆决策，工具是否产生副作用，回答是否有证据，失败后谁负责恢复，这些才决定系统能否进入企业流程。
反例复盘可以从三类样本开始。第一类是“看起来完成了，但责任不清”的样本，例如 Agent 自动发送报告，却没有确认接收者和权限。第二类是“答案正确，但证据不足”的样本，例如模型给出合规建议，却无法说明引用了哪个制度版本。第三类是“流程顺畅，但无法审计”的样本，例如工具调用成功，Trace 却没有保存参数、审批和输出 artifact。每一类样本都能把 Agent 与 Copilot、Workflow、RAG 的边界讲清楚。
早期平台可以把这些反例放进准入材料。一个新 Agent 上线前，团队先回答它会不会替用户行动，行动是否有副作用，证据是否可追踪，失败是否可恢复，责任 owner 是否明确。若这些问题没有答案，就应停留在助手或工作流增强阶段。这样全书后续讨论的 Runtime、工具、Memory、HITL、Trace 和 Guardrails，都会回到同一条边界线。
1.17 Agent 边界的运行证据¶
Agent 边界进入生产后，新增能力不能只看功能是否可用，还要看运行证据能否被不同角色复用。平台需要把决策主体、工具副作用、审批点、执行回执和审计记录记录成稳定字段，并和发布单、Trace、评测样本以及事故记录关联起来。这样一次线上问题发生后，团队可以沿着同一组事实判断影响范围、责任归属和修复顺序，而不是在模型日志、业务日志和人工说明之间来回拼接。
这类证据还要服务相邻章节的能力。它和第22章 Runtime、第30章 HITL 和第50章安全相连：上游能力提供输入假设，下游能力使用执行结果，治理能力负责保存证据和复审结论。若这些材料没有统一编号和版本，章节里讨论的工程能力在生产中会被拆散。业务 owner 只能看到用户投诉，平台 owner 只能看到系统错误，安全或合规团队只能看到事后说明，最后很难判断问题到底来自数据、模型、工具、流程还是组织责任。
生产环境中常见的风险包括演示阶段任务看似完成，生产阶段却无法证明谁做了决策、谁批准了副作用。这些问题在演示阶段不明显，因为演示通常只覆盖成功路径；上线后，用户会带来边界问题、重复请求、权限变化和长时间运行状态。平台团队应把失败样本纳入发布节奏，记录哪些样本需要阻断发布，哪些样本可以通过降级处理，哪些样本需要业务 owner 接受剩余风险。
Agent 边界应通过运行证据确认，帮助读者区分交互体验和责任转移。这份记录不需要复杂，但要包含时间、版本、owner、样本、处置动作和下次复查条件。没有这些字段，复盘会停留在口头经验；有了这些字段，平台才能把一次问题转成后续发布、评测和培训材料。
早期平台可以从少量高风险场景开始。先选择调用量高、业务影响大或涉及敏感数据的路径，要求每次变更都留下证据包，再逐步推广到普通场景。这样章节里的能力不会停留在概念层，而会成为可运行、可解释、可退回的工程系统。
本章小结¶
Agent 不是大模型应用的总称。它是一类围绕任务目标组织感知、决策、行动和反馈的系统。RAG、Copilot、Workflow 和 Agent 各有边界，企业项目里的许多问题看起来像模型能力不足，根源常在需求分类一开始就做错了。企业级 Agent 的难点不在于让系统更像人，而在于让系统知道哪些动作可以自动完成，哪些动作需要确认，哪些动作必须留下证据。本书从平台讲起，也是因为系统一旦能在企业里推进任务，问题就会进入运行、权限、审计和治理层，无法停留在模型层。下一章会继续讨论平台边界：企业建设的是一组 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.