Agent 进企业以后，最先要补的不是模型，而是控制平面
企业里最危险的 AI 叙事，是把 agent 描述成“会自己干活的数字员工”，然后跳过一个现实问题：数字员工也需要身份、权限、岗位边界、操作日志、主管审核和离职回收。
当 AI 只是回答问题时，风险主要是答错。当 AI agent 能调用工具、读写文件、发邮件、改 CRM、跑脚本、查数据库、提交代码、触发退款时，风险变成了系统风险。它不再只是模型问题，而是控制平面问题。
这个控制平面决定：agent 能看什么、能做什么、何时必须停下、谁负责审核、错误如何回滚、成本如何计量、经验如何沉淀。
为什么 prompt 不是核心边界
很多早期 agent 项目依赖 prompt 管边界：告诉模型“不要做高风险动作”“遇到不确定要询问”“不要泄露数据”。这当然有必要，但远远不够。
原因很简单：prompt 是软约束，企业权限是硬约束。一个生产 agent 必须假设模型会误解、会忘记、会被诱导、会遇到上下文缺口，也会因为工具返回异常而进入奇怪路径。
真正的企业控制平面至少要包含八个对象：
| 对象 | 需要回答的问题 |
|---|---|
| Agent 身份 | 这个 agent 代表谁运行？是个人、团队还是服务账号？ |
| 权限范围 | 它能读哪些数据，能写哪些系统，能否跨租户？ |
| 工具目录 | 哪些工具可用，参数 schema 是什么，是否可组合？ |
| 上下文边界 | 哪些文档、客户、项目、邮件可以进入 prompt？ |
| 风险等级 | 哪些动作必须人工确认，哪些动作永远禁止？ |
| 评估机制 | 如何知道 agent 这次做对了？ |
| 审计日志 | 谁触发、模型看了什么、调用了什么、写了什么？ |
| 生命周期 | agent 如何上线、版本化、暂停、回滚、删除？ |
没有这些对象，企业 agent 就会变成“能力很强但没人敢放权”的演示产品。
评估基础设施是生产门槛
Microsoft 2026 Work Trend Index 里有一个非常实用的判断：agent 执行越多，人类评估基础设施越重要。一次坏输出可以人工改掉，但当坏输出在流程里规模化传播，风险会复合。
这也是 Morgan Stanley 案例最值得学的地方。它不是直接让模型服务顾问，而是先建立 eval：真实问题集、专家评分、回归测试、检索质量调优、会议摘要评估。金融服务里的 AI 之所以能被顾问大规模采用，不是因为模型会说金融话，而是因为企业建立了“可被信任的验证过程”。
我建议企业把 eval 分成四层：
| eval 层 | 检查内容 | 例子 |
|---|---|---|
| 输入 eval | 用户意图、权限、上下文是否正确 | 是否把个人客户数据错误带入团队 agent |
| 中间过程 eval | 检索、工具选择、参数是否合理 | 是否调用了错误 CRM 对象 |
| 输出 eval | 答案、摘要、计划是否准确 | 是否遗漏会议 action item |
| 行为 eval | 写入、发送、提交、退款等动作是否合规 | 是否越权发送客户邮件 |
传统软件测试主要验证代码路径。agent eval 要验证“模型 + 工具 + 数据 + 人”的组合路径。
工具调用的真实难点：野生用户行为
很多 benchmark 会把 tool calling 简化成“给定 API schema，模型生成正确参数”。但真实企业用户不会这样说话。
WildToolBench 这类研究指出，真实用户行为包含组合任务、跨轮隐式意图、临时改口、闲聊和任务指令混杂等问题。评测 57 个模型时，没有模型在该基准上达到 15% 以上准确率。这不一定说明模型“很差”，而是说明真实 tool-use 远比静态函数调用复杂。
企业系统里常见的失败路径包括：
- 用户先问分析，下一轮突然要求执行；
- 用户说“就按上次那个客户的条件来”，但上下文里有多个客户；
- 用户在一个请求里混合查询、修改和发送；
- 工具返回部分失败，模型继续假装成功；
- agent 错把闲聊当成操作确认；
- 多个系统字段名字相似，参数映射出错。
所以控制平面必须把 tool calling 设计成可中断、可回滚、可确认的流程，而不是一次性函数调用。
一个企业 Agent 控制平面草图
这里有几个关键设计：
第一，工具不直接暴露给模型，而是经过 Tool Broker。Tool Broker 负责 schema、参数校验、幂等、权限和回滚。
第二，风险门控不应该只靠模型判断。退款、删除、发邮件、改权限、提交代码、转账、上传文件等动作应有硬规则。
第三，评估结果要回写 playbook。否则每次错误都只是一次客服工单，不会变成系统能力。
成本控制也是控制平面
agent 比 chatbot 贵，不是因为单次模型更贵，而是因为一次任务会展开成多次检索、推理、工具调用、重试和验证。
企业需要把成本作为一等对象：
- 每个任务记录 token、模型、工具耗时、重试次数；
- 高价值任务允许用强模型，低价值任务自动路由到小模型或规则；
- 重复任务用缓存、模板和脚本；
- 长流程设置预算，超过预算自动降级或请求确认；
- 统计哪些 agent 真正带来节省，哪些只是制造调用量。
没有成本层，agent 很容易在试点时看起来聪明，上规模后变成不可控账单。
可靠性不只靠更强模型
近期一些企业级 agent 研究开始从“单模型能力”转向“系统可靠性”。例如 Six Sigma Agent 论文提出用任务分解、多模型采样和共识机制降低错误；Salesforce 的 compound AI 部署研究关注多模型 fan-out、冷启动传播、动态扩缩容和尾延迟；安全场景里的 CHASE 则把 LLM 与确定性安全工具组合，避免模型单独承担恶意包分析。
这些方向背后的共同结论是：企业可靠性来自架构，而不是来自相信模型下一代会变完美。
更强模型可以提高上限，但控制平面决定下限。
结论
企业部署 agent，第一阶段会问“它能不能做事”。第二阶段会马上问“它能不能被管理”。
真正能进入生产的 agent，不是最会聊天的，而是最容易被纳入企业治理的：有身份、有权限、有工具边界、有评估、有审计、有成本记录、有人工接管、有回滚机制。
未来企业 AI 平台的竞争，表面上看是模型和应用，底层会越来越像控制平面之争。谁能把 agent 当成可管理的企业实体，而不是一个神秘对话框，谁才更接近真实落地。
来源与延伸阅读
- Microsoft Work Trend Index 2026
https://www.microsoft.com/en-us/worklab/work-trend-index/agents-human-agency-and-the-opportunity-for-every-organization - OpenAI：Morgan Stanley eval-driven AI adoption
https://openai.com/index/morgan-stanley/ - arXiv：Benchmarking LLM Tool-Use in the Wild
https://arxiv.org/abs/2604.06185 - arXiv：The Six Sigma Agent
https://arxiv.org/abs/2601.22290 - arXiv：Scalable Inference Architectures for Compound AI Systems
https://arxiv.org/abs/2604.25724 - arXiv：CHASE: LLM Agents for Dissecting Malicious PyPI Packages
https://arxiv.org/abs/2601.06838