从顺丰看Agent:行业都在拼智商,企业真正缺的是手脚

进入顺丰总部做 AI 后，我开始同时生活在两种语言里。

一边是模型、Agent、MCP、Skill、工具调用。技术世界每天都在讨论，模型又学会了什么，Agent 又能替人完成多少工作。

另一边是业务、系统、权限、责任和异常。企业真正关心的是，这件事能不能做对，数据能不能看，动作能不能撤回，做错以后谁来接。

两边聊的好像是同一件事，关注点却完全不同。

技术团队关心 Agent 会不会做。

企业关心的是，敢不敢让它做。

这种反差，让我越来越确定一个判断。

企业做 Agent，最先该建设的不是更多 Agent，而是一套 Agent 可以安全调用的能力体系。

Agent 只是能力的消费者。

企业真正需要沉淀的资产，是那些可发现、可授权、可组合、可审计、可撤销的业务能力。

这不是一个纯技术问题。

它涉及企业如何把多年积累的数据、流程、规则和业务经验，重新整理成机器可以理解、系统可以执行、组织敢于授权的数字基础设施。

顺丰这类大型物流网络，有几个很鲜明的特点。

高频、跨系统、强时效、异常多、责任链长。

一票快件从揽收到派送，背后可能经过多个节点、多个角色和多套系统。正常情况下，流程按规则流转，传统软件和自动化已经能解决很多问题。

真正难的是异常。

客户临时修改信息，上游数据还没有同步；两个系统显示了不同状态；标准规则覆盖不了某个特殊场景；现场情况已经变化，后台仍然停留在几分钟前；一个问题横跨多个责任主体，却没有人能从单一页面看到全貌。

这时，系统知道发生了什么，并不代表它知道下一步该怎么办。

SOP 记录的是正常情况下怎么走，Know-how 决定的是路断了以后往哪走。

物流让我重新理解了 Agent。

Agent 最难的，不是完成一条设计好的正常流程，而是在数据缺失、规则冲突、系统延迟和现场变化同时出现时，判断自己还能不能继续行动。

它要知道什么时候查证据，什么时候换一条路径，什么时候降低结论的确定性，什么时候停下来找人。

一个真正进入企业生产环境的 Agent，不能只有做事的能力。

它还要有一种更难的能力，知道自己的行动边界在哪里。

这也是企业 Agent 和普通聊天机器人的分水岭。

聊天机器人说错一句话，我们把它叫作幻觉。人看一眼，发现不对，重新生成就行。

Agent 会把模型输出变成真实动作。

它可能查询客户信息、生成报价、创建工单、发送邮件、提交审批、调整库存、修改系统状态。每接入一个工具，它就多了一只可以伸进真实业务里的手。

问题也随之改变。

语言模型的判断具有概率性，企业系统的执行却是确定性的。

模型可能只是“大概理解了”，系统却会真的发出消息、修改数据、推动流程。

上游是概率世界，下游是责任世界。

企业 Agent 的建设，不能只研究如何让模型更会思考，还要解决概率判断如何穿过组织边界，变成一个被允许、被约束、被记录的动作。

外界讨论 Agent，常常先问模型。

用哪个模型？推理能力怎么样？上下文有多长？工具调用准不准？

这些当然重要。

但站到企业一线以后，我越来越觉得，模型只是整条链路中的一部分。

同一个模型放进两家公司，最后可能表现得像两个完全不同的产品。

一家公司的 Agent 只能读知识库、写摘要、回答制度问题。遇到真实流程，它只能提醒员工“请前往相关系统处理”。

另一家公司的 Agent 可以在明确的权限范围内查询订单、拉取证据、匹配规则、识别异常、生成处置建议、发起审批，并把结果写回业务系统。

模型可能一样。

差距来自企业内部有多少真实业务能力，已经被整理成 Agent 可以调用的服务。

我把这件事概括成一个不严谨，但很实用的公式。

这是一个乘法关系。

模型再聪明，不能调用真实能力，只能停在聊天框里。

能力再丰富，组织不敢授权，只能停在演示环境里。

权限全部开放，却没有边界和治理，结果可能更危险。它会把模型的一次错误，放大成生产系统里的真实事故。

所以，企业 Agent 的上限并不只由模型决定。

它还取决于企业愿意把多少经营能力整理出来，并用多大的信任半径交给机器。

OWASP 在“Excessive Agency”中，把 Agent 风险归纳为三个重要来源。

功能过多、权限过大、自治程度过高。

一个只需要读取文档的 Agent，却拿到了修改和删除权限。一个只需要查询数据库的工具，却使用了同时拥有增删改查权限的账号。一个高影响动作，在没有独立校验和人工确认的情况下直接执行。

你会发现，危险不只来自模型不够聪明。

真正的风险，是一个不够稳定的决策者，被交付了过大的行动半径。

这有点像让一名聪明但经验不足的实习生进入公司核心系统。

你不会因为他会写报告，就顺手把财务章、管理员密码和客户通讯录一起交给他。你会给他任务，也会给他权限，但权限一定跟着任务走。

不少企业对 Agent 的授权，却仍然比较粗放。

团队先为它配置一个服务账号，再把完成任务可能用到的权限一次性加上。开发阶段这样做很快，进入生产后却会留下一个问题。

Agent 真正需要的权限，和账号已经拥有的权限，并不是一回事。

NIST 的零信任架构强调，不应该因为网络位置或资产归属给予隐式信任，每一次访问具体资源前，都要完成主体认证和授权。

Agent 正是一类新的非人主体。

它进入企业内网，不等于自动可信。它由公司开发，也不等于可以访问所有公司资源。它代表某位员工工作，也不应该自动继承这位员工的全部权限。

不要因为 Agent 足够聪明，就给它隐式权力。

智能可以来自模型。

权力必须来自组织授权。

聊到能力体系，技术团队可能会说，我们已经有 API 平台，也开始建设 MCP Server 和 Skills 了，这不就是能力体系吗？

我觉得还差一步。

API 解决的是系统之间如何通信。

MCP 解决的是模型如何用相对统一的方式发现和调用工具。

Skill 更像任务层的操作手册，告诉 Agent 在某个场景下如何组合知识、规则和工具。

它们都很重要。

但企业级能力不能只回答“怎么调用”，还得把一组更现实的问题说清楚。

谁在调用？代表谁调用？在什么业务场景下调用？可以操作什么对象？影响范围有多大？失败后如何停止、补偿和追责？

我在企业 AI 落地中感受很深的一点是，业务和技术对“能力”的理解经常不在同一个频道。

技术团队说接口已经有了。

业务团队却仍然觉得，AI 什么都做不了。

因为接口描述的是系统动作。

查询一条数据、更新一个字段、创建一张工单、发送一条消息。

业务需要的却是完整任务。

判断这是不是异常，找到异常发生在哪一段，确定应该由谁处理，给出下一步建议，判断是否需要升级，确认最后有没有闭环。

接口是技术世界的最小单元，任务才是业务世界的最小单元。

企业能力体系要做的，就是把两者翻译到一起。

比如“查询客户订单”可以是一项能力。

但它不能只留下一个 getOrder 接口。它还要说明哪些角色可以查、能查哪些客户、能看到哪些字段、是否需要脱敏、一次能查多少条、结果能否带出系统、调用记录保存多久。

“发送退款通知”也可以是一项能力。

它需要绑定退款状态、通知模板、收件人范围、渠道规则和审批条件。Agent 可以发起调用，但不能自由修改收款账户，也不能绕过退款流程直接向客户承诺到账。

这才是 Agent 能放心使用的能力。

接口让系统连接，能力让责任闭环。

今天很多企业的软件建设方式，是围绕应用展开的。

CRM 有一套功能，ERP 有一套功能，客服系统有一套功能，供应链平台又有一套功能。同一个“查询订单”动作，可能散落在多个系统、多个接口和多套权限里。

人可以通过培训记住去哪里点。

Agent 不该靠猜。

如果企业未来会出现十个、一百个甚至更多 Agent，每个团队都重新对接一次底层系统，最后一定会形成新的烟囱。

销售 Agent 自己接 CRM，客服 Agent 再接一次 CRM，经营分析 Agent 又做一套数据库查询工具。权限各配一遍，口径各解释一遍，日志各存一遍。

表面上 Agent 越来越多，实际上企业只是把过去的系统烟囱，复制成了新的 Agent 烟囱。

所以，第一步不是列出“我们要做哪些 Agent”，而是画出一张企业能力地图。

这张地图至少要回答三类问题。

企业里有哪些稳定、可复用的业务动作？

哪些动作只读取信息，哪些动作会改变业务状态？

哪些动作可以自动执行，哪些必须保留人的批准权？

按这个思路，可以先把能力分成几类。

信息能力，例如查订单、查库存、查制度、查客户历史。重点是数据范围、字段脱敏和使用目的。

分析能力，例如识别异常、计算风险、生成经营摘要。重点是数据口径、规则版本、置信度和结果解释。

交易能力，例如创建订单、修改价格、提交退款、调整库存。这类能力会改变业务状态，需要强化授权、幂等、限额、审批和补偿机制。

沟通能力，例如发送邮件、通知客户、创建群聊、发起外呼。这类能力直接影响企业对外表达，需要控制收件人、内容模板、敏感信息和发送频率。

控制能力，例如暂停任务、撤销操作、冻结账号、触发应急流程。这些能力平时不显眼，却决定 Agent 出错后企业有没有刹车。

当这些能力被统一识别、分级和治理后，Agent 才能像搭积木一样组合它们。

今天是客服 Agent 调用“查订单＋识别异常＋创建工单”。

明天是供应链 Agent 调用“查库存＋判断缺货风险＋发起调拨”。

后天换了模型，甚至换了 Agent 平台，底下这套能力仍然存在。

Agent 会快速迭代，企业能力应该成为慢变量。

企业盘点能力时，很容易从已有系统出发。

系统有什么接口，我们就开放什么工具。

但从复杂物流网络看，这个顺序仍然不够贴近业务。

因为正常流程中的动作，往往已经被软件固化。真正依赖经验的部分，大多藏在异常处理里。

面对一票异常订单，业务骨干不会只看一个状态字段。

他可能会先看运单轨迹，再对照产品规则，判断异常发生在哪个节点；接着看客户历史和服务承诺，评估影响；如果证据不完整，他会知道还需要找哪个角色确认；如果涉及特殊客户或高风险承诺，他会主动升级。

这套工作很少完整写在一份 SOP 里。

它散落在不同系统、不同文档和老员工的经验中。

所以，企业能力不应该只按照“系统有什么接口”来组织。

它更应该按照“业务遇到问题时，需要完成哪些判断和动作”来组织。

以异常处置为例，一套可复用能力可能包括：

这些能力一旦被拆出来，就不只服务某一个 Agent。

客服、运营、质量、经营分析等不同场景，都可能复用其中一部分。

这也是我理解的企业 Know-how 数字化。

不是把老师傅的经验整理成一篇更长的文档，也不是把所有资料扔进知识库让模型检索。

而是把“看到什么信号、如何形成判断、接下来采取什么动作”这条链路拆出来，变成可调用、可验证、可持续改进的能力。

知识回答“你知道什么”，能力回答“遇到这件事，你下一步怎么做”。

能力体系听起来容易变成一个大词。

为了避免把它做成又一轮抽象的中台建设，我更愿意把它拆成六道具体的门。

第一扇门，是可发现

Agent 必须知道企业有哪些能力，每项能力适合解决什么问题。

这不只是给工具取个名字。

能力描述要包含业务含义、适用场景、输入输出、风险等级、负责人、版本和限制条件。名称也必须准确。

“处理订单”这种工具就太宽了。

它到底是查询、创建、修改还是取消？动作越模糊，Agent 误用的空间越大。

能力应该尽量原子化，让读取和写入分开，让建议和执行分开，让普通操作和高风险操作分开。

工具描述不是说明文档，它本身就是安全边界的一部分。

第二扇门，是可识别

每一个 Agent 都应该拥有独立身份，而不是共享一个万能账号。

它是谁创建的？属于哪个部门？服务哪个业务流程？当前代表哪位用户行动？使用长期服务身份，还是用户委托身份？

这些信息必须贯穿整条调用链。

没有独立身份，就没有真正的最小权限，也没有准确审计。

出了问题，只能查到“某个公共账号调用了接口”。到这一步，责任链已经断了。

第三扇门，是可授权

身份解决“你是谁”，授权解决“你现在能不能做这件事”。

企业不应该只在 Agent 上线时做一次静态授权，然后让它长期持有权限。

更稳妥的方式，是在每次能力调用前，根据调用者、被代表的用户、具体动作、业务对象、运行环境、时间、流程节点和风险等级重新判断。

MCP 的企业托管授权扩展，也在把企业身份提供方变成集中授权决策点。员工身份、群组、角色和组织策略，可以统一决定哪些 MCP Server 能被访问，并支持集中撤权。

但允许访问某个 MCP Server，不等于允许调用其中所有工具。允许调用“订单工具”，也不等于可以修改任何订单。

真正的最小权限，要细到每一次动作、每一个对象和每一个上下文。

第四扇门，是可约束

授权通过了，也不代表可以无限制执行。

一次最多查询多少客户？一天最多发送多少封邮件？退款金额超过多少必须人工确认？能否在生产环境执行？能否把结果传给外部模型？调用参数是否符合业务规则？

这些限制应该由独立的策略和业务规则执行，而不是写进提示词后祈祷模型遵守。

提示词可以提醒 Agent，但不能承担最终控制责任。

AWS 在 Agentic AI Lens 中给出的建议很直接，每次工具调用都应在执行前由外部网关依据策略授权，并传播 Agent 身份和用户上下文。高风险写操作还应设置人工复核。

不能让 Agent 同时担任申请人、审批人和执行人。

第五扇门，是可观察

传统应用出了问题，我们查接口日志。

Agent 出了问题，只看接口日志往往不够。

企业需要看到完整链路。

是谁提出了目标，Agent 如何拆解任务，读取了哪些信息，选择了什么工具，携带了哪些参数，哪条策略允许或拒绝了调用，最终改变了什么业务状态，消耗了多少模型与系统资源。

日志不能只服务事故发生后的追责。

它还应该帮助企业发现某项能力被异常频繁调用、某个 Agent 的行为模式突然改变、某项能力失败率升高、某类任务成本失控。

没有可观察性，Agent 的自治就会变成企业的失明。

第六扇门，是可干预

很多团队设计 Agent 时，只设计成功路径。

企业更应该先设计失败路径。

执行到一半怎样暂停？重复调用怎样避免重复扣款？更新错了数据怎样补偿？Agent 连续失败是否自动熔断？发现越权调用后，能否立刻撤销身份和令牌？高风险任务能否切换成人工接管？

一项成熟能力不只包含执行接口，还应该带着幂等、超时、重试、熔断、补偿和撤销机制。

真正成熟的能力，不只知道怎么把事做成，也知道做错后如何收回来。

再往深一层看，企业 Agent 建设并不只是技术升级。

它会重新分配“谁可以代表企业采取行动”这项权力。

过去，一名员工能做什么，由岗位、系统账号、审批流程和组织制度共同决定。

Agent 出现后，企业增加了一类新的行动主体。

它可以跨系统工作，可以持续运行，可以在短时间内执行大量动作，而且不会因为疲劳降低频率。

如果能力建设仍然由各个项目组各自完成，谁先接入系统，谁就可能在事实上定义 Agent 的行动边界。

业务规则藏在提示词里，权限固化在服务账号里，风险判断由项目团队临时决定。

表面上这是开发效率。

实际上，它把一部分企业治理权悄悄下放给了单个项目。

所以，能力体系不能只是 IT 部门建设一个工具市场。

它需要业务、技术、安全、数据和审计共同参与。

业务负责人定义能力的真实语义和业务边界。

系统负责人保证接口稳定、数据准确、失败可恢复。

安全团队设计身份、权限、密钥和策略。

数据团队明确字段分级、脱敏和流转限制。

审计与合规团队定义日志保存、证据链和责任追溯要求。

每一项进入生产环境的高价值能力，都应该有明确的所有者。

谁负责它的正确性？谁批准权限范围？谁在异常时有权关闭？谁决定它什么时候下线？

企业真正缺的往往不是一个更聪明的 Agent，而是一套能把数字权力说清楚的制度。

“先建设能力体系”不等于先花一年时间做一个覆盖全公司的超级平台，也不等于把所有旧系统推倒重来。

这条路我们太熟悉了。

先画一张宏大的架构图，再定义几百个标准。等平台建完，业务场景已经变了，最后留下一套昂贵但没人愿意使用的中台。

Agent 时代尤其不能这么干。

模型、协议和交互方式都在快速变化，企业很难一次性设计出最终形态。

能力体系应该从真实任务中长出来。

先选一个价值明确、风险可控、调用频率足够高的流程。把这个流程需要的能力抽出来，做清楚身份、权限、策略、审计和异常处理。再用第二个 Agent 或第二个业务场景复用这些能力，验证它们是否真的脱离了单一项目。

能力只有被第二个场景复用，才开始从项目代码变成企业资产。

还有一条边界必须看清。

不是所有业务动作都适合交给 Agent。

不可逆、强合规、高金额、涉及人身安全或重大权益的决策，Agent 可以收集材料、给出建议、检查规则，却不一定应该拿到最终执行权。

自主程度不是越高越先进。

合适的自主程度，才是成熟。

我常用一个非正式框架帮助团队讨论风险。

这不是一个严格的数学模型，但它能提醒我们，任何一项明显升高，都应该提高授权门槛、缩小自动化范围，或者增加人工批准。

企业做 Agent，不该追求彻底无人。

应该追求的是，在责任清楚的前提下，让机器多做一步。

进入企业一线以后，我也在重新理解企业 AI 这份工作的价值。

它不是替企业多接几个模型，也不是帮每个部门分别做一个聊天机器人。

更重要的工作，是进入真实流程，找到那些高频、关键、依赖经验的业务动作，再把它们翻译成机器能够理解、系统能够执行、组织能够治理的能力。

这个过程至少要完成三次翻译。

把业务问题翻译成可计算的任务。

把可计算任务翻译成可调用的能力。

把模型输出翻译成组织敢于接受的行动。

我愿意把这套方法叫作“企业 Know-how 编译链”。

它大致经过七个环节。

找任务，不是问业务想要什么 AI 功能，而是找到那些高频发生、消耗大量人工、又需要经验判断的工作。

拆判断，是把“老师傅一看就知道”打开，找到他看了哪些信号、排除了哪些可能、为什么选择下一步动作。

找证据，是确认每一个结论依赖哪些数据、规则、文档和历史案例。

封能力，是把分散在多个系统里的动作整理成有清晰业务语义的服务。

加边界，是为能力配置身份、权限、限额、审批、审计和异常机制。

跑闭环，是让结果真正回到业务流程中，而不是停在对话框里。

验证复用，是用第二个场景检验它究竟是一段项目代码，还是一项组织资产。

这也是我希望长期研究和沉淀的方向。

把业务专家脑子里的判断，编译成组织可以安全调用的数字能力。

从真实任务出发，盘点高频能力

不要先开会讨论要做多少个 Agent。

先选三到五个最想落地的真实任务，把它们拆成读取、判断、写入、沟通和控制动作，再看哪些动作在多个任务里反复出现。

反复出现的，才值得优先沉淀为共享能力。

例如客户服务、销售支持和经营分析都需要查询客户与订单信息，那么“受控的客户信息查询”比某个单独 Agent 更值得先建设。

建立能力目录，同时标注风险等级

每项能力至少记录业务定义、输入输出、数据分级、读写属性、风险等级、系统负责人和当前使用方。

不要等治理平台成熟后再补。

哪怕最开始只用一张表，也比能力散落在代码仓库和个人脑子里强。

尤其要先把“读”和“写”分开。

查询库存和调整库存，不应该是同一项模糊能力。生成退款建议和执行退款，也不应该共享同一权限。

建立独立于 Agent 的执行控制面

所有真正影响业务状态的调用，尽量经过统一的执行入口。

这个入口负责校验身份、传播用户上下文、评估策略、检查参数、记录日志、执行限流，并在必要时发起人工审批。

Agent 负责理解目标、规划步骤和提出调用请求。

控制面负责决定请求能不能被执行。

让模型负责智能，让确定性系统负责底线。

用第二个场景验证复用，不要急着扩 Agent 数量

第一个 Agent 跑通，只能证明团队完成了一个项目。

第二个 Agent 能在不重新对接底层系统、不重新申请一套万能账号、不重新解释业务规则的情况下复用已有能力，才证明企业开始拥有平台资产。

真正的规模化，不是复制 Agent 的代码。

企业 Agent 的规模化，是持续降低新 Agent 获得合规能力的成本。

模型能力会继续提高，Agent 框架也会快速迭代。

今天大家争论哪个模型更适合推理，明天可能又有更强的新模型出现。把所有优势押在模型和框架上，企业很难形成长期壁垒。

真正难复制的，是企业多年积累下来的流程、数据、规则和行业 Know-how，能否被整理成机器可以安全调用的能力。

这也是顺丰这样的复杂网络带给我的启发。

系统规模越大，真正值钱的越不只是写在制度和 SOP 里的显性知识。

更值钱的，往往是大量业务人员在异常、冲突和不确定中形成的判断。

过去，这些判断依附于个人经验。

有人调岗、退休或者离开，组织就可能重新交一次学费。

Agent 提供了一个新的机会。

企业可以把这些经验从“某个人会做”，逐步变成“组织可以调用”。但前提不是把资料全部交给模型，而是把经验拆成信号、判断、动作和边界，再纳入企业原有的身份、权限与责任体系。

所以，别把企业 Agent 建设理解成再做一个 AI 应用。

它更像一次能力重构。

过去，企业把能力装进一个个软件页面里，等人去点击。

接下来，企业要把能力从页面里拆出来，变成人、Agent 和自动化流程都可以调用的服务，同时为每一次调用配上身份、边界和责任。

我不想把自己的工作理解成“帮企业多做几个 Agent”。

我更关心的是，如何把业务专家的判断、系统里的动作和组织的责任边界，编译成机器可以安全调用的生产力。

因为模型决定机器有多聪明。

能力体系决定它能走进多深的业务。

而组织授权，决定它最终能替企业承担多少行动。

智能来自模型，权力来自组织，能力体系连接两者。

OWASP LLM06:2025 Excessive Agency：

https://genai.owasp.org/llmrisk/llm062025-excessive-agency/

OWASP Top 10 for Agentic Applications：

https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai

NIST SP 800-207 Zero Trust Architecture：

https://csrc.nist.gov/pubs/sp/800/207/final

Model Context Protocol Enterprise-Managed Authorization：

https://modelcontextprotocol.io/extensions/auth/enterprise-managed-authorization

AWS Agentic AI Lens，Implement tool authorization：

https://docs.aws.amazon.com/wellarchitected/latest/agentic-ai-lens/agentsec02-bp01.html

Microsoft Entra Agent ID，Authorization：

https://learn.microsoft.com/entra/agent-id/identity-professional/authorization-agent-id