企业建设 Agent 时，很容易把“能连接多少系统、调用多少工具”当成能力进步。采购演示也常沿着同一条路线展开：让 Agent 查客户、读合同、改订单、发邮件、建工单、跑报表，连接越多，似乎越接近一个真正的数字员工。
但 10 月 9 日，Postman 与 AWS 公布的一组生产经验给出了相反信号。Postman 在为其 Agent Mode 扩展工具时发现，当模型一次可见的工具超过约 40 个，工具选择错误开始增加：它可能调用不存在的工具、传入错误参数，或选择一个语义相近但不适合当前情境的工具。换用更新、更大的模型能缓解问题，却没有消除它。
Postman 后来的做法不是继续把全部能力塞给模型，而是从 170 多个工具中，按当前任务动态筛选约 15 个，再交给隔离的执行线程。
这项实践揭示了一个对企业更重要的判断：Agent 的生产能力，不取决于它理论上会做多少事，而取决于企业能否为每项任务提供一小块相关、清晰、受控的能力范围。
我们可以把这块范围称为“任务能力面”。它同时回答五个问题：当前任务需要什么事实、允许使用哪些工具、每个工具能操作哪些对象、哪些动作必须确认，以及什么证据代表任务完成。
“全部接入”会把系统复杂性转嫁给模型
传统软件由开发者预先决定按钮、页面和调用顺序。Agent 则需要根据自然语言，在运行时判断要调用哪个工具、如何组合参数、何时停止。工具数量增加，不只是菜单变长，还会同时扩大三种不确定性。
第一种是选择不确定性。两个工具的名称和描述可能相似，但适用的业务对象、数据时点或权限不同。例如“更新客户信息”与“提交客户主数据变更”看似接近，后者却可能触发审批、同步多个系统，并影响账单与合规记录。
第二种是组合不确定性。单个调用可能正确，多步组合后却产生未预期结果。读取客户名单、生成文件和对外发送邮件分别都可能是合法能力，串联起来就可能形成敏感数据外发。
第三种是上下文不确定性。Agent 即使选对工具，也可能对“当前客户”“正在处理的订单”“规则适用日期”或“用户已经确认到哪一步”理解错误。Postman 的经验是，缺失或不完整的上下文比缺少工具造成了更多失败。把原本为界面渲染和数据传输设计的对象直接序列化给模型，也没有形成有效上下文，因为界面数据结构并不等同于完成任务所需的业务事实。
因此，把现有 API、插件和后台权限一次性交给 Agent，并不是在减少集成工作，而是在要求模型临场理解多年积累的系统边界、界面假设和隐含规则。
任务能力面不是一张静态工具白名单
如果只是为所有任务配置同一张工具白名单，问题仍然存在。真正的任务能力面应随业务意图、对象状态、用户身份和风险等级动态生成。
以“处理一笔客户退款”为例，企业不应先问 Agent 可以连接哪些系统，而应先定义完成这项任务所需的最小能力：
这样设计后，Agent 每次面对的不是企业全部数字能力，而是一份临时、受约束的任务工作台。任务结束后，相关能力和短期权限也随之回收。
这与传统角色权限并不冲突。角色权限回答“这个人通常可以做什么”，任务能力面进一步回答“这一次、为了这个对象、在这个阶段，Agent 代表他可以做什么”。前者是长期资格，后者是逐任务授权。
NIST 今年关于软件与 AI Agent 身份和授权的概念文件也把识别、授权、审计、不可否认性及提示注入防护列为核心问题。它所提示的方向是：Agent 不能只继承一个宽泛的服务账号；企业需要知道究竟是哪一个 Agent、代表谁、依据什么授权、对什么资源执行了什么动作。
- 能力层：需要明确的内容
- 任务事实：订单、付款、履约、退货、客户身份与当前争议状态
- 规则依据：适用政策版本、合同条款、时限、地区及例外条件
- 可用工具：查询订单、计算可退金额、创建申请，而不是全部财务与客服工具
- 对象范围：仅能操作当前客户与当前订单，不能横向读取其他客户或批量修改
- 动作边界：查询和草拟可自动完成；付款、外部通知或高额例外需要独立确认
- 完成证据：退款进入哪个状态、记录写入何处、客户收到什么通知、失败如何升级
先把“读取”做成业务语义，再逐步开放动作
许多团队为了控制工具数量，会为每一个问题制作一个小工具。短期看精确，长期却会形成工具膨胀：查状态、查错误率、查延迟、查七天趋势分别拥有不同接口，模型需要先从大量相似入口中猜测该用哪一个。
Postman 对结构化数据采取了另一种方式：让 Agent 基于明确的数据结构生成查询，从服务运行、测试结果和响应时间等数据中组合答案。工程工作由“为每个问题做一个工具”转向“把数据模型和可读边界设计好一次”。
对企业而言，这不意味着允许 Agent 任意查询生产数据库。更稳妥的做法，是提供经过治理的业务语义层：
读取适合在受控语义层上提供一定组合空间，写入则应保持明确、狭窄、可验证。企业不应为了减少工具数量，把多种高风险写操作合并成一个“万能执行”接口；那只是用更少的工具名称换来了更大的权限半径。
- 字段含义、口径、时间范围和数据责任人清晰；
- 行、列、租户和用途权限由系统确定性执行；
- 查询资源、返回行数和敏感字段有硬限制；
- 读取结果带来源、时点和版本，不能被当成永远有效的事实；
- 写入能力仍通过更窄的专用动作接口开放。
工具描述本身也属于供应链
任务能力面不只解决准确率，也直接影响安全边界。
OWASP 的 MCP 安全指南指出，Agent 会看到所连接服务器提供的工具描述，而工具名称、参数结构和返回内容都可能成为提示注入或工具投毒的载体。一个昨天获批的工具，也可能在定义或后台行为变化后成为新的风险来源。指南因此建议对每个服务器和工具实施最小权限，固定并校验已审查的工具结构，隔离敏感工具，对输入和输出进行验证，并在破坏性、财务或数据共享动作前要求明确确认。
这意味着企业不能把“已经接入 MCP”视为一次性验收。工具目录本身应像 API、依赖包和身份权限一样进入持续治理：
这里有一个常被忽略的经营含义：工具目录不是“技术集成清单”，而是一份 Agent 可以代表企业做什么的产品目录。目录越大，维护、评测、授权、审计和事故响应成本也越高。
- 每个工具要有业务所有者、允许用途和数据分级；
- 工具描述、参数、返回结构或权限变化时重新评审；
- 内部敏感工具与外部检索工具处于不同信任域；
- 每次运行记录当时实际暴露的工具集合及其版本；
- 监测异常组合，而不只监测单个调用是否成功；
- 停用长期未用、功能重叠或无法说明业务价值的工具。
上线验收不能只测“最终答案对不对”
传统对话评测常检查回答是否准确、完整、通顺。具备工具能力的 Agent 还需要验证过程，因为同一个正确答案可能通过不必要的敏感读取、错误工具重试或越权调用得到。
企业至少应建立四层验收：
任务层：是否真正完成用户目标，是否在正确业务对象上操作，是否在应该停止时停止。
选择层：暴露给模型的工具是否足够且最小，工具选择、参数和顺序是否合理，是否出现不存在的工具或无效重试。
授权层：读取、写入、对外发送和不可逆动作是否经过相应策略与确认，权限是否只在必要时间和对象范围内有效。
经济层：端到端耗时、调用次数、上下文成本、人工确认成本和失败恢复成本是否优于原流程，而不是只比较单次模型价格。
验收用例也不能只来自正常路径。应加入同名对象、过期规则、缺失字段、权限临界点、恶意文档、相似工具、工具版本变化和中途取消等情形，观察系统是否缩小能力面、请求补充事实或安全退出。
特别需要避免把 Postman 披露的“约 40 个工具”当成行业阈值。它只是特定产品、模型、工具定义和测试条件下观察到的现象，公开资料没有给出样本量、错误率曲线、任务分布、对照模型或最终业务成效。170 多个缩减到约 15 个同样是该系统的架构实例，不是所有企业都应照抄的数字。
真正可以迁移的不是数字，而是方法：把工具数量当作需要管理的认知与风险预算，用真实任务测试能力面，而不是默认“接得越多越好”。
从一个高频任务开始，而不是先建设万能 Agent
企业可以从一条高频、跨系统但风险可控的任务入手，例如供应商资料更新、销售报价准备、设备维护信息归集或客户退款预审。
先记录人工完成任务时真正使用的事实、系统、判断和例外，再建立最小工具集合；把读取、建议、草拟、提交和执行分成不同权限层；用历史任务回放比较人工与 Agent 的工具路径；最后才根据缺失证据增加能力，而不是根据系统已有 API 批量接入。
每次新增工具前，都应回答三个问题：它解决了哪类已观察到的任务失败？现有工具为什么不能安全完成？加入后将增加哪些评测、权限和维护责任？如果无法回答，新工具更可能是在扩张演示范围，而不是提高生产结果。
成熟企业真正的优势，从来不是拥有最多系统连接，而是能把复杂组织能力切分成边界清楚、证据充分、可逐步授权的任务单元。
下一阶段的企业 Agent 竞争，也许不会取决于谁先做出一个“什么都能做”的入口，而取决于谁能让 Agent 在每一个具体时刻，只看到完成当前任务所需的世界，并且只拥有完成当前任务所需的能力。
