一家做跨境零售的客户上周跟我聊起一件事：他们给客服系统接了个 agent，让它自动处理退款。上线第一周风平浪静，第二周却发现——有笔异常退款在没人察觉的情况下，连续触发了三十多次，等财务月底对账才暴露。钱没丢多少，但"系统自己跑了、人不知道"这件事，把他们的 CIO 吓出一身冷汗。
这不是孤例。把最近一周企业级 AI 代理的动态摆在一起看，会发现一个清晰的信号：行业已经从"怎么让 agent 动起来"，转向"怎么让 agent 动得可控"。控制层，正在从 PPT 上的原则，变成平台里原生的刹车系统。
第一道刹车：评估先行，让"跑没跑错"可被观测
过去我们判断一个自动化靠不靠谱，靠的是上线前测试加人工抽查。但 agent 不一样——它会根据上下文自己决定下一步，同样的输入今晚和明早可能走出不同路径。传统"测一次就上线"的套路，在 agent 身上基本失效。
Salesforce 最近给 Agent Fabric 加的 Agent Evals，做的就是这件事：对 agent 本身做持续测试与评估，同时对它依赖的 API 做变更侦测。换句话说，agent 不是在真空中跑，它调用的每一个接口一旦悄悄改了返回结构、改了字段含义，评估层就能在"出错之前"报警。
这件事的启发在于：企业把 agent 接进 ERP 之前，先要问清——我的平台能不能在运行时持续验证 agent 的行为？如果答案是"只能上线后靠人肉看日志"，那这个 agent 舰队规模越大，雷就埋得越深。评估不是上线后的补丁，而是 agent 的出厂设置。
第二道刹车：身份前置，给 agent 发"身份证"
当系统里跑的不再只是人，还有大量"非人类身份"，一个更隐蔽的问题浮出来：你怎么知道正在改这条记录的，是张三是李四，还是一个伪装成自动化的恶意 agent？
Socure 最近推出的 Agent Intelligence，把这件事产品化了。它的 Agent Detection 已经正式可用，Agent TrustScore 在内测，可验证的 Agent Credential 计划明年一季度推出。核心逻辑是 KYA（Know Your Agent）——识别 agent 流量，按身份、授权、风险打分，并发放把 agent 绑回某个自然人或企业主体的凭证。与此同时，Resemble 发布的行为检测模型，针对"伪装成普通自动化"的 agent，内部基准检测率达到约 98.8%，远高于传统机器人工具不到 15% 的水平。
对 ERP 场景，这意味着"给 agent 开账号"会像"给员工开账号"一样，需要一套身份治理。在放开 agent 写单、付款、改库存之前，先建立 agent 身份目录与信任评分，是比"上多少个 agent"更前置的功课。一个没有身份、没有信任分的 agent，再聪明也不该碰核心单据。
第三道刹车：熔断与封顶，把失控关进笼子
最让 CFO 夜不能寐的，是"费用失控"。按量计费的 agent 一旦逻辑出错或被人刷接口，账单可以几小时内炸穿月预算。Salesforce 这次同步给出的 kill-switch（一键熔断）与硬支出上限，正是冲着这个痛点去的——异常时运营方一键切断，单个 agent 的消耗被锁死在预算内。
这给所有准备上量 agent 的企业提了个醒：你的 agent 平台，是否提供运行时评估、熔断与支出封顶这三件套？缺任何一样，"上规模"就等于"上风险"。尤其在 ERP 这种直接碰资金、库存、凭证的系统里，高利害动作（改账、付款、发单）永远不该设成"全自动"，至少要留一道人工闸门和一条硬性预算线。
三道刹车，一条主线
把这三件事连起来，主线很清楚：agent 能"动"之前，必须先能"被识别、被评估、被切断、被追责"。这是 agent 从实验走向规模生产的分水岭，也是监管和法务迟早会追问的底线。
对正在选型或准备上量的 CIO，我给一份很实在的控制层清单：
第一，身份先建，权限后给。每个能碰系统的 agent，都要有身份目录、信任评分和明确的责任主体（绑回哪个自然人或部门）。匿名 agent 不进生产环境。
第二，评估常开，变更必报。agent 与其调用的 API 都要有运行时评估；接口一改结构，先预警再放行，别等出错。
第三，熔断与封顶是出厂配置，不是选配。高利害动作一律留人工闸门，单 agent 消耗有硬上限，异常能一键切断。
第四，底座主权握在自己手里。无论选闭源大厂还是开源路线，确保身份日志可自留、成本可核验、规则可自写。以 Odoo 20 这类开源底座为例，MCP 原生、数据 100% 自有，治理逻辑由你自己定义，不会被国际平台的合规框架与按量计费黑箱双重绑架。
说到底，agentic ERP 的竞争，上半场比谁先把代理接进去，下半场比谁先装好刹车。装好了，agent 才是杠杆；没装，它只是把失控自动化了。
