微软 Agent Control Specification：为什么 Agent 审批会成为企业 AI 基础设施

微软发布了 Agent Control Specification，一个用于 AI Agent 运行时治理的开放、供应商中立规范。TechCrunch 也报道了这次发布，重点是让开发、安全和合规团队用更一致、更细粒度的方式控制 Agent 行为。

这件事的重点，不是 Agent 又多了一个配置文件。

真正重要的是：企业 AI 正在进入 Agent 可以检索数据、调用工具、执行工作流、跨系统行动的阶段。一旦软件开始代表人类行动，核心问题就不再只是“模型能做什么”，而是 Agent 到底被允许做什么，谁来批准它继续做。

ACS 把治理放进运行时

很多组织现在仍然用 prompt、应用代码、框架 callback 和零散校验来管理 Agent 行为。实验阶段可以，生产环境会很脆弱。

微软把 ACS 定义为 controls layer，而不是 agent framework。它用一个可移植的 manifest，定义 policy 在 Agent 生命周期的哪些位置、什么时机、以什么方式被评估和执行，并且不绑定某个 Agent 框架、运行时或 policy engine。

换句话说，ACS 给企业 Agent 控制提供了一份共同契约：

• 在用户输入进入模型前检查；
• 在模型调用前检查完整上下文；
• 在 runtime 根据模型输出行动前检查；
• 在工具调用执行前检查；
• 在工具返回结果重新进入上下文前检查；
• 在最终回复离开 Agent 前检查；
• 在启动和关闭时检查配置、日志和审计条件。

每个节点上，policy 都可以给出 allow、warn、deny 或 escalate。

这是一个很关键的变化。Guardrails 不再只是写在 prompt 里的建议，而变成绑定在 Agent 行为上的运行时决策。

企业真正的新问题是审批

Agent 越有用，越会接触真实业务系统：邮件、工单、CRM、代码仓库、客户数据、财务流程、内部文档、部署工具。

传统权限控制可以回答“这个 credential 能不能调用这个资源”。但 Agent 时代的问题更复杂：考虑到这个 Agent 已经看过什么、即将调用什么工具、涉及哪些数据标签、当前有没有审批状态，这个动作现在还安全吗？

所以审批会变成基础设施。

不是老式 OA 里层层卡人的审批，而是更精确的控制面：

• 哪些动作可以自动执行；
• 哪些动作必须人类批准；
• 哪些敏感数据需要遮蔽；
• 哪些工具调用必须阻断；
• 哪些证据必须留下来方便审计；
• 哪些失败必须 fail closed。

Agent 管理正在成为产品层

ACS 也说明，Agent 管理不能被简化成模型选择。

更强的模型也许推理更好，但它不会自动生成 policy、审计、升级处理、证据收集和人类接管机制。这些是系统责任。

对企业来说，真正长期有价值的是 Agent 外围那一层：身份、权限、工作空间上下文、工具边界、日志、审批门和改进闭环。Agent 会越来越像数字员工，而不是插件。

这和 Buda 的关系

Buda 的判断也是一样：Agent 应该在 human-led system 里工作。

Buda 的 Space 定义组织边界。Agent 在这个边界里使用文件、会话、终端、浏览器、channels、artifacts 和任务。人类可以审查工作、调整指令、批准敏感动作，也可以在需要时接管。

ACS 说明整个生态也在走向同一个方向。Agent 越能干，公司越需要显式控制面：审批、policy、审计、升级处理和 human oversight。

企业 AI 的未来，不只是更多 autonomous agents。

而是更好管理的 agents。

你可以在 buda.im 开始构建 human-led agent workflows，也可以阅读 Buda Agent Workspace 文档。