最近圈子里讨论最多的除了各家模型参数表的更新就是阿里云放出的那份 Alibaba Cloud AI Agent Handbook。很多人把它当成产品文档翻完就扔一边但我觉得里面藏着一个被低估的概念——智能面积。这个词乍一听有点抽象但它直接回应了做智能体AI Agent时最让人头疼的问题你的 Agent 到底能扛多大面积的活儿我在实际落地项目里见过太多 Demo 跑得飞起、一上生产就趴窝的 Agent问题往往不是模型不够聪明而是从一开始就没想清楚面积画在哪里。这篇文章把手册里和智能面积相关的思路结合我自己做 Agent 落地的经验拆开来聊聊。1. 智能面积是什么别再把 Agent 当成一个函数1.1 从单点任务到业务面积前两年大家做 Agent习惯把它理解成一个函数输入问题输出答案中间最多套几步工具调用。这种思维方式最大的问题是把 Agent 当成一个没有厚度的点。你说它能做问答它就只做问答你说它能查天气它就只查天气。可真实业务不是点状分布的它是一块一块拼起来的面积。打个比方。你圈了一块地打算在上面盖个客服中心。如果只看单点能力你可能只需要一个能回答快递到哪了的机器人。但真正的业务面积包括用户进来先分流查订单走查订单的系统问售后走售后的工单流程遇到情绪激动的人要转人工转人工之前还得把前面的对话小结递过去。这一整套下来Agent 不再是单个函数而是覆盖整条业务路径的面积。手册里讲的智能面积我理解的核心就是一件事不要只看 Agent 会不会某一个动作要看它在多大的业务半径内能自主、连续、可靠地完成任务。就像你不能因为一个人会炒鸡蛋就说他能开饭店面积考量的不是单点技能而是从入口到出口的全流程覆盖面。1.2 手册里智能面积的三层含义我翻完手册后把智能面积拆成了三层。这三层互相叠加共同决定一个 Agent 在真实场景里到底顶不顶用。第一层是工具与系统接入面。Agent 能触达多少个内部 API、外部数据源、遗留系统。这一层决定它手脚能伸多远。很多企业的 Agent 只接了知识库问答没接订单系统也没接库存系统那它的业务面积天然就小一圈。第二层是上下文与记忆的持续面。Agent 能不能记住用户上次说了什么能不能跨多轮会话保持业务状态这决定了它的面积有没有纵深。没有记忆的 Agent每次对话都是重新开始做不了任何连续性的业务。第三层是人与 Agent 的协同面。不是所有任务都该让 Agent 独立干完面积还包括它与人工、与其他 Agent 之间的交接与协作边界。这三层合起来才构成完整的业务面积。单点工具再强没有系统接入面积是零接入再多没有记忆面积的深度不够记忆再深没有协同设计面积是碎的。维度单点工具形态有面积的 Agent 形态系统接入只接知识库问答打通订单、库存、工单、CRM 多套系统记忆能力每轮对话无状态跨会话记住用户偏好与业务状态协同方式答不了直接丢给人工先归纳小结再交接给人工并附上下文业务覆盖处理孤立的 FAQ覆盖从分流到完结的完整任务链路这张表我建议直接打印出来做 Agent 架构时候对着看能少走很多弯路。2. 决定智能面积的天花板技术底盘怎么选2.1 模型选型与规划能力对面积的影响做 Agent 先要选模型但选模型不是在排行榜上挑分高的而是要挑规划能力匹配业务面积的。什么叫规划能力就是模型能不能把一个大任务拆成多个小步骤并且在执行过程中根据中间结果调整后续动作。比如售后客服场景里用户说我的耳机坏了想换货。面积够大的 Agent 会先调订单接口确认购买记录再调售后策略判断是否符合换货条件接着生成退货单最后告诉用户寄回地址。这一串动作如果模型规划能力弱很可能第一步调完订单就懵了不知道下一步该干什么。规划能力直接影响 Agent 能覆盖的路径长度。我自己的经验是模型选型不用一味追求最大参数。参数大推理强但成本和延迟都会翻倍。关键是看模型在多步工具调用 中途纠错上的表现。你先拿自己业务里最复杂的一条流程去试看它能不能在中间结果出现意外时自己转弯。能转弯的模型面积才做得大一遇到意外就死机的模型参数再高也得换掉。2.2 工具调用与函数协议面积的第一层地基Agent 接触业务系统全靠工具调用工具协议写得好不好直接决定面积能铺多大。很多团队在起步阶段图省事把工具描述写得很潦草结果模型根本不知道这个工具什么时候该用。我见过一个项目里面接了个库存查询接口描述只写了查询库存四个字结果模型在用户问某款笔记本还有货吗的时候完全没把它和库存接口关联起来。工具协议里我认为有三样东西缺一不可一是用途说明要写清楚这个工具解决什么问题、在什么条件下用二是参数的语义要写完整比如日期格式、单位换算、默认值都要交代干净三是返回结果的异常要从业务角度描述比如接口超时、数据不存在时返回什么让模型知道怎么应对。另外还要注意权限设计。工具不是接得越多越好而是要把每个工具的调用范围限定在 Agent 的业务面积之内。比如客服 Agent 可以查订单但不能改订单价格可以看库存数量但不能调整库存。权限边界画清楚既保护业务安全也让模型更清楚自己的职责范围。2.3 记忆与上下文工程面积的时间维度业务面积不只是平面上的宽度还有时间上的纵深。一个用户六个月前找你退过货今天又来咨询新订单如果 Agent 把这些全忘了那服务体验就是断裂的。上下文工程要解决的就是让 Agent 在时间维度上也能覆盖到。短期记忆靠对话窗口这个大家都熟但窗口再大也有天花板。我的做法是把业务数据主动沉淀成结构化记忆用户 ID、订单状态、历史投诉原因、偏好渠道这些在每轮对话结束时抽出存到外部存储里。下一轮会话开始时再通过检索把相关记忆放回上下文。这里有个容易踩的坑窗口长度不等于记忆能力。很多模型宣称支持超长上下文但那只是把更多 token 塞进输入不等于它知道什么该记住、什么该丢弃。你需要自己做记忆筛选和摘要否则上下文越长模型越容易在无关信息里迷路。把记忆当成一份长期维护的数据资产而不是临时塞进上下文的文本垃圾面积的时间维度才靠得住。2.4 多 Agent 协同从单块地到连片开发单 Agent 的面积再大也总有自己的边界。业务复杂到一定程度把多个 Agent 组合起来互相当工具、互相接力是扩大面积的自然选择。但多 Agent 不是堆数量而是设计好路由和交接。我常用的是主从模式加轻量路由。入口 Agent 负责理解用户意图并做初步分流然后把任务派给对应的专业子 Agent——订单问题派给订单 Agent售后问题派给售后 Agent。子 Agent 干完活后把结果归纳好交回入口 Agent由它统一组织回答。这样主入口保持着统一的服务面积感知各子 Agent 在各自的窄面积里做深做精整体面积反而更可控。多 Agent 协同最常见的翻车点是信息在交接过程中蒸发。子 Agent A 查到的订单编号没传给子 Agent BB 就只能让用户重新说一遍。解决办法是把上下文传参做成强约束交接时强制带上关键业务字段宁可数据冗余也不要信息断裂。这是我在多个项目里被反复教育出来的经验。3. 实操把自己 Agent 的面积从 0 画到能落地3.1 先画一张面积地图动手写代码之前我建议团队先坐在一起画一张面积地图。方法很简单把 Agent 将来要处理的所有任务逐条列出来每条任务标注四件事——需要调用哪些工具、需要依赖哪些知识、需要记住哪些状态、业务边界在哪儿。别怕这张表刚开始画得丑。我曾经带着团队画一个电商客服 Agent 的面积地图画了三天最后发现我们最初设想的简单客服实际涉及七个业务系统、四种用户身份、三条必须转人工的兜底路径。如果不提前画出来后面架构一定返工。面积地图里最容易被漏掉的是边界外任务。你不想让 Agent 处理什么问题、什么问题必须坚决报错、什么问题需要转人工这些在面积地图阶段就要写死。边界画清楚Agent 才不会在拿不准的时候硬编答案。3.2 搭建一个够用的维度以售后客服 Agent 为例我拿一个做过的模拟项目举例项目代号就叫售后客服 Agent。它的业务场景是用户在电商平台申请退换货Agent 要完成从受理到指引寄回的全流程。工具层我们接了三套系统订单查询接口、售后工单创建接口、运费补贴规则库。知识层挂了一个 RAG 知识库放了退换货政策、仓储配送说明、常见问题清单。记忆层做了一张用户会话状态表记录用户当前处于申请中待寄回已完成哪个阶段避免用户每次都要重讲一遍。边界层定义了两类转人工一类是用户情绪激烈触发风险词另一类是超过平台规定的退换货时间窗口Agent 无权处理。整个链路跑下来用户说我上周买的鞋小了想换大一码Agent 先调订单接口确认购买信息再查退换货政策判断是否符合条件然后调工单接口创建换货申请最后生成一个含寄回地址和注意事项的完整回复。这个面积不算大但已经覆盖了一条完整的业务路径。3.3 面积衡量的单位面积产出面积画出来还得有办法衡量它够不够用。我习惯于盯三个指标。第一个指标是首次解决率用户问一个问题Agent 一次搞定没有转人工、没有让用户重复描述就叫首次解决。第二个指标是面积外话术率Agent 生成的回复里有多少句是在说这个问题我无法处理或者请稍等转人工。这个比率太高说明面积画小了或工具接入不够。第三个指标是人机交接频次每个交接背后都是成本交接太少说明 Agent 可能在越权硬扛交接太多说明能力不足。这三个指标结合起来能帮你判断面积到底缺在哪。首次解决率低可能是工具调用链路不通面积外话术率高可能是知识库覆盖不全或边界定义太保守人机交接频次高可能是子 Agent 的路由设计有问题。用数据盯面积比凭感觉调 prompt 靠谱得多。4. 常见问题与避坑实录面积是怎么悄悄缩水的4.1 坑一只给了浏览权没给操作权很多团队做 Agent 时出于安全考虑只给工具开只读权限。结果 Agent 能查订单、能看库存但用户一问能不能帮我改个地址它就卡住了因为改地址的接口权限没开。表面上看工具接入面挺大实际业务面积是零。我的经验是权限设计要么分级要么带审批流。分级的意思是查、改、批三档权限按业务场景分给不同 Agent审批流的意思是高风险操作必须经人工确认后执行但 Agent 要能把操作意图完整清晰地呈现给人工。有了这条Agent 才敢真正碰业务系统面积才落得下来。4.2 坑二上下文一长前面的事情全忘了上下文工程没做好最常见的症状是聊了半小时后Agent 突然问你最开始想处理什么问题来着用户当场就怒了。窗口长度再大模型也很难在所有历史信息里准确捕捉对当前决定最重要的那部分。我的解法是给每个业务会话做一个滚动状态摘要。每轮对话结束时把当前完成事项、未决事项、下一步动作整理成结构化摘要存起来。下一轮先读摘要再读最新对话而不是把全量历史都塞进上下文。这个做法对降低幻觉、保持业务连续性的效果立竿见影。别迷信长窗口要迷信好的记忆工程。4.3 坑三用评测集只测单轮问答不测面积边界我见过太多团队拿一个问答对列表做评测每个问题独立打分分数看着挺高一上线就露馅。因为真实用户不会按评测集提问他们会追问、会打断、会一口气提出三个请求、会要求改前面已经回答过的东西。评测一定要分三类做。第一类做单轮准确性这是及格线。第二类做多轮连续性把一个完整业务场景从头到尾跑一遍看 Agent 是否始终记得上下文。第三类做边界探测故意提 Agent 不该处理的问题看它能不能得体地拒绝、正确地转人工。这三类都过了面积才算经得起真实使用。4.4 坑四忽略人工兜底面积有些团队为了追求自动化率把所有人工入口都堵死逼 Agent 硬扛所有问题。这样做出来的面积是虚胖扛不住的 Case 最终一定会变成事故。人机协同不是把难问题踢给客服而是要把交接做顺、做细。我的做法是在业务路径的关键节点预留人工兜底位。Agent 判断自己处理不了时要把已确认的信息、用户的诉求、Agent 尝试过的步骤整理好形成一份交接摘要连同会话记录一起转给人工。人工拿到手的是一份完整的上下文而不是用户再从零讲一遍。兜底面积做得好自动化率反而更高因为用户对及时转给真人的体验是正向的。注意面积不是画得越大越好。边界清不清楚、兜底稳不稳、工具权限合不合理比面积的数量级更要紧。宁可一块一块把面积做实也不要看起来铺得很大、用起来处处漏风。我个人在实际操作里的体会是做完 Agent 架构后一定要拿真实业务流量去压测面积不是压模型的推理能力而是压整条业务链路在异常输入下的表现。压出问题别急着改 prompt先回去看面积地图和工具协议大部分面积缩水都是架构问题不是指令问题。还有一个小技巧把每个 Agent 的业务边界用一句话写死在系统提示词和路由配置里团队协作时特别管用它能防止不同人维护的 Agent 之间职责混乱也能让模型在面对边界外任务时更快做出拒绝或转交决策。这层显式边界声明是我在多个项目里踩过坑之后才补上的补完再也没出现过 Agent 抢着回答不该答的问题这种尴尬情况。 
长河君 · 2026/10/18 12:11:04 · 阅读 1.2k 智能面积：AI Agent 业务覆盖能力的核心概念与落地实践
最近圈子里讨论最多的除了各家模型参数表的更新就是阿里云放出的那份 Alibaba Cloud AI Agent Handbook。很多人把它当成产品文档翻完就扔一边但我觉得里面藏着一个被低估的概念——智能面积。这个词乍一听有点抽象但它直接回应了做智能体AI Agent时最让人头疼的问题你的 Agent 到底能扛多大面积的活儿我在实际落地项目里见过太多 Demo 跑得飞起、一上生产就趴窝的 Agent问题往往不是模型不够聪明而是从一开始就没想清楚面积画在哪里。这篇文章把手册里和智能面积相关的思路结合我自己做 Agent 落地的经验拆开来聊聊。1. 智能面积是什么别再把 Agent 当成一个函数1.1 从单点任务到业务面积前两年大家做 Agent习惯把它理解成一个函数输入问题输出答案中间最多套几步工具调用。这种思维方式最大的问题是把 Agent 当成一个没有厚度的点。你说它能做问答它就只做问答你说它能查天气它就只查天气。可真实业务不是点状分布的它是一块一块拼起来的面积。打个比方。你圈了一块地打算在上面盖个客服中心。如果只看单点能力你可能只需要一个能回答快递到哪了的机器人。但真正的业务面积包括用户进来先分流查订单走查订单的系统问售后走售后的工单流程遇到情绪激动的人要转人工转人工之前还得把前面的对话小结递过去。这一整套下来Agent 不再是单个函数而是覆盖整条业务路径的面积。手册里讲的智能面积我理解的核心就是一件事不要只看 Agent 会不会某一个动作要看它在多大的业务半径内能自主、连续、可靠地完成任务。就像你不能因为一个人会炒鸡蛋就说他能开饭店面积考量的不是单点技能而是从入口到出口的全流程覆盖面。1.2 手册里智能面积的三层含义我翻完手册后把智能面积拆成了三层。这三层互相叠加共同决定一个 Agent 在真实场景里到底顶不顶用。第一层是工具与系统接入面。Agent 能触达多少个内部 API、外部数据源、遗留系统。这一层决定它手脚能伸多远。很多企业的 Agent 只接了知识库问答没接订单系统也没接库存系统那它的业务面积天然就小一圈。第二层是上下文与记忆的持续面。Agent 能不能记住用户上次说了什么能不能跨多轮会话保持业务状态这决定了它的面积有没有纵深。没有记忆的 Agent每次对话都是重新开始做不了任何连续性的业务。第三层是人与 Agent 的协同面。不是所有任务都该让 Agent 独立干完面积还包括它与人工、与其他 Agent 之间的交接与协作边界。这三层合起来才构成完整的业务面积。单点工具再强没有系统接入面积是零接入再多没有记忆面积的深度不够记忆再深没有协同设计面积是碎的。维度单点工具形态有面积的 Agent 形态系统接入只接知识库问答打通订单、库存、工单、CRM 多套系统记忆能力每轮对话无状态跨会话记住用户偏好与业务状态协同方式答不了直接丢给人工先归纳小结再交接给人工并附上下文业务覆盖处理孤立的 FAQ覆盖从分流到完结的完整任务链路这张表我建议直接打印出来做 Agent 架构时候对着看能少走很多弯路。2. 决定智能面积的天花板技术底盘怎么选2.1 模型选型与规划能力对面积的影响做 Agent 先要选模型但选模型不是在排行榜上挑分高的而是要挑规划能力匹配业务面积的。什么叫规划能力就是模型能不能把一个大任务拆成多个小步骤并且在执行过程中根据中间结果调整后续动作。比如售后客服场景里用户说我的耳机坏了想换货。面积够大的 Agent 会先调订单接口确认购买记录再调售后策略判断是否符合换货条件接着生成退货单最后告诉用户寄回地址。这一串动作如果模型规划能力弱很可能第一步调完订单就懵了不知道下一步该干什么。规划能力直接影响 Agent 能覆盖的路径长度。我自己的经验是模型选型不用一味追求最大参数。参数大推理强但成本和延迟都会翻倍。关键是看模型在多步工具调用 中途纠错上的表现。你先拿自己业务里最复杂的一条流程去试看它能不能在中间结果出现意外时自己转弯。能转弯的模型面积才做得大一遇到意外就死机的模型参数再高也得换掉。2.2 工具调用与函数协议面积的第一层地基Agent 接触业务系统全靠工具调用工具协议写得好不好直接决定面积能铺多大。很多团队在起步阶段图省事把工具描述写得很潦草结果模型根本不知道这个工具什么时候该用。我见过一个项目里面接了个库存查询接口描述只写了查询库存四个字结果模型在用户问某款笔记本还有货吗的时候完全没把它和库存接口关联起来。工具协议里我认为有三样东西缺一不可一是用途说明要写清楚这个工具解决什么问题、在什么条件下用二是参数的语义要写完整比如日期格式、单位换算、默认值都要交代干净三是返回结果的异常要从业务角度描述比如接口超时、数据不存在时返回什么让模型知道怎么应对。另外还要注意权限设计。工具不是接得越多越好而是要把每个工具的调用范围限定在 Agent 的业务面积之内。比如客服 Agent 可以查订单但不能改订单价格可以看库存数量但不能调整库存。权限边界画清楚既保护业务安全也让模型更清楚自己的职责范围。2.3 记忆与上下文工程面积的时间维度业务面积不只是平面上的宽度还有时间上的纵深。一个用户六个月前找你退过货今天又来咨询新订单如果 Agent 把这些全忘了那服务体验就是断裂的。上下文工程要解决的就是让 Agent 在时间维度上也能覆盖到。短期记忆靠对话窗口这个大家都熟但窗口再大也有天花板。我的做法是把业务数据主动沉淀成结构化记忆用户 ID、订单状态、历史投诉原因、偏好渠道这些在每轮对话结束时抽出存到外部存储里。下一轮会话开始时再通过检索把相关记忆放回上下文。这里有个容易踩的坑窗口长度不等于记忆能力。很多模型宣称支持超长上下文但那只是把更多 token 塞进输入不等于它知道什么该记住、什么该丢弃。你需要自己做记忆筛选和摘要否则上下文越长模型越容易在无关信息里迷路。把记忆当成一份长期维护的数据资产而不是临时塞进上下文的文本垃圾面积的时间维度才靠得住。2.4 多 Agent 协同从单块地到连片开发单 Agent 的面积再大也总有自己的边界。业务复杂到一定程度把多个 Agent 组合起来互相当工具、互相接力是扩大面积的自然选择。但多 Agent 不是堆数量而是设计好路由和交接。我常用的是主从模式加轻量路由。入口 Agent 负责理解用户意图并做初步分流然后把任务派给对应的专业子 Agent——订单问题派给订单 Agent售后问题派给售后 Agent。子 Agent 干完活后把结果归纳好交回入口 Agent由它统一组织回答。这样主入口保持着统一的服务面积感知各子 Agent 在各自的窄面积里做深做精整体面积反而更可控。多 Agent 协同最常见的翻车点是信息在交接过程中蒸发。子 Agent A 查到的订单编号没传给子 Agent BB 就只能让用户重新说一遍。解决办法是把上下文传参做成强约束交接时强制带上关键业务字段宁可数据冗余也不要信息断裂。这是我在多个项目里被反复教育出来的经验。3. 实操把自己 Agent 的面积从 0 画到能落地3.1 先画一张面积地图动手写代码之前我建议团队先坐在一起画一张面积地图。方法很简单把 Agent 将来要处理的所有任务逐条列出来每条任务标注四件事——需要调用哪些工具、需要依赖哪些知识、需要记住哪些状态、业务边界在哪儿。别怕这张表刚开始画得丑。我曾经带着团队画一个电商客服 Agent 的面积地图画了三天最后发现我们最初设想的简单客服实际涉及七个业务系统、四种用户身份、三条必须转人工的兜底路径。如果不提前画出来后面架构一定返工。面积地图里最容易被漏掉的是边界外任务。你不想让 Agent 处理什么问题、什么问题必须坚决报错、什么问题需要转人工这些在面积地图阶段就要写死。边界画清楚Agent 才不会在拿不准的时候硬编答案。3.2 搭建一个够用的维度以售后客服 Agent 为例我拿一个做过的模拟项目举例项目代号就叫售后客服 Agent。它的业务场景是用户在电商平台申请退换货Agent 要完成从受理到指引寄回的全流程。工具层我们接了三套系统订单查询接口、售后工单创建接口、运费补贴规则库。知识层挂了一个 RAG 知识库放了退换货政策、仓储配送说明、常见问题清单。记忆层做了一张用户会话状态表记录用户当前处于申请中待寄回已完成哪个阶段避免用户每次都要重讲一遍。边界层定义了两类转人工一类是用户情绪激烈触发风险词另一类是超过平台规定的退换货时间窗口Agent 无权处理。整个链路跑下来用户说我上周买的鞋小了想换大一码Agent 先调订单接口确认购买信息再查退换货政策判断是否符合条件然后调工单接口创建换货申请最后生成一个含寄回地址和注意事项的完整回复。这个面积不算大但已经覆盖了一条完整的业务路径。3.3 面积衡量的单位面积产出面积画出来还得有办法衡量它够不够用。我习惯于盯三个指标。第一个指标是首次解决率用户问一个问题Agent 一次搞定没有转人工、没有让用户重复描述就叫首次解决。第二个指标是面积外话术率Agent 生成的回复里有多少句是在说这个问题我无法处理或者请稍等转人工。这个比率太高说明面积画小了或工具接入不够。第三个指标是人机交接频次每个交接背后都是成本交接太少说明 Agent 可能在越权硬扛交接太多说明能力不足。这三个指标结合起来能帮你判断面积到底缺在哪。首次解决率低可能是工具调用链路不通面积外话术率高可能是知识库覆盖不全或边界定义太保守人机交接频次高可能是子 Agent 的路由设计有问题。用数据盯面积比凭感觉调 prompt 靠谱得多。4. 常见问题与避坑实录面积是怎么悄悄缩水的4.1 坑一只给了浏览权没给操作权很多团队做 Agent 时出于安全考虑只给工具开只读权限。结果 Agent 能查订单、能看库存但用户一问能不能帮我改个地址它就卡住了因为改地址的接口权限没开。表面上看工具接入面挺大实际业务面积是零。我的经验是权限设计要么分级要么带审批流。分级的意思是查、改、批三档权限按业务场景分给不同 Agent审批流的意思是高风险操作必须经人工确认后执行但 Agent 要能把操作意图完整清晰地呈现给人工。有了这条Agent 才敢真正碰业务系统面积才落得下来。4.2 坑二上下文一长前面的事情全忘了上下文工程没做好最常见的症状是聊了半小时后Agent 突然问你最开始想处理什么问题来着用户当场就怒了。窗口长度再大模型也很难在所有历史信息里准确捕捉对当前决定最重要的那部分。我的解法是给每个业务会话做一个滚动状态摘要。每轮对话结束时把当前完成事项、未决事项、下一步动作整理成结构化摘要存起来。下一轮先读摘要再读最新对话而不是把全量历史都塞进上下文。这个做法对降低幻觉、保持业务连续性的效果立竿见影。别迷信长窗口要迷信好的记忆工程。4.3 坑三用评测集只测单轮问答不测面积边界我见过太多团队拿一个问答对列表做评测每个问题独立打分分数看着挺高一上线就露馅。因为真实用户不会按评测集提问他们会追问、会打断、会一口气提出三个请求、会要求改前面已经回答过的东西。评测一定要分三类做。第一类做单轮准确性这是及格线。第二类做多轮连续性把一个完整业务场景从头到尾跑一遍看 Agent 是否始终记得上下文。第三类做边界探测故意提 Agent 不该处理的问题看它能不能得体地拒绝、正确地转人工。这三类都过了面积才算经得起真实使用。4.4 坑四忽略人工兜底面积有些团队为了追求自动化率把所有人工入口都堵死逼 Agent 硬扛所有问题。这样做出来的面积是虚胖扛不住的 Case 最终一定会变成事故。人机协同不是把难问题踢给客服而是要把交接做顺、做细。我的做法是在业务路径的关键节点预留人工兜底位。Agent 判断自己处理不了时要把已确认的信息、用户的诉求、Agent 尝试过的步骤整理好形成一份交接摘要连同会话记录一起转给人工。人工拿到手的是一份完整的上下文而不是用户再从零讲一遍。兜底面积做得好自动化率反而更高因为用户对及时转给真人的体验是正向的。注意面积不是画得越大越好。边界清不清楚、兜底稳不稳、工具权限合不合理比面积的数量级更要紧。宁可一块一块把面积做实也不要看起来铺得很大、用起来处处漏风。我个人在实际操作里的体会是做完 Agent 架构后一定要拿真实业务流量去压测面积不是压模型的推理能力而是压整条业务链路在异常输入下的表现。压出问题别急着改 prompt先回去看面积地图和工具协议大部分面积缩水都是架构问题不是指令问题。还有一个小技巧把每个 Agent 的业务边界用一句话写死在系统提示词和路由配置里团队协作时特别管用它能防止不同人维护的 Agent 之间职责混乱也能让模型在面对边界外任务时更快做出拒绝或转交决策。这层显式边界声明是我在多个项目里踩过坑之后才补上的补完再也没出现过 Agent 抢着回答不该答的问题这种尴尬情况。