让 Agent 真正进入业务系统，缺的可能不是模型，而是一份能力契约

Anivia...

327人浏览 · 2026-07-13 18:18:34

Anivia... · 2026-07-13 18:18:34 发布

最近在思考一个越来越现实的问题：

大模型已经能理解自然语言，Agent 也能调用工具，但如果真的让它进入企业现有的订单、库存、退款、员工、客户和工单系统，它到底应该看到哪些能力？哪些操作必须绑定真实用户？哪些操作风险较高？什么时候需要审批？调用之后又该如何审计和追溯？

这些问题显然不是再换一个更强的模型就能解决的。

从“能调用接口”到“可以进入业务”

假设一家门店希望让 Agent 帮助员工处理业务：

查询某个订单；
查看库存；
修改商品信息；
创建退款；
导出客户资料；
删除员工账号。

从技术上看，这些能力都可以做成 API，也可以通过 Function Calling 或 MCP 暴露给 Agent。

但“接口能被调用”并不等于“接口适合直接交给 Agent”。

查询订单和创建退款的风险完全不同；修改商品名称和删除员工账号的后果也不同。企业还需要知道，这次操作是谁发起的、模型提交了什么参数、是否经过审批、最终调用了哪个接口，以及执行结果是什么。

当这些问题出现后，我逐渐意识到，Agent 接入业务系统之间缺少的，其实是一层公共的能力声明语义。

后来看到 ACC

沿着这个问题继续查找，我看到了 ACC，也就是 Agent Capability Contract，Agent 能力契约。

ACC 面向的是 A2B，也就是 Agent-to-Business 场景：让 Agent 能够在明确边界下使用已有业务系统提供的能力。

它不是另一个 Agent 框架，也不负责替代业务系统的权限体系，更不是新的接口描述语言。

OpenAPI 继续描述接口路径、参数和返回值；ACC 则在 OpenAPI 之上补充 Agent 使用业务能力时需要理解的治理语义，例如：

这个能力是否允许向 Agent 暴露；
它对应什么业务范围；
是否必须绑定可信的操作主体；
风险等级是什么；
是否具有审批意图；
审计数据是否包含敏感内容；
是否只读、幂等以及建议的超时和限流；
Agent 应该在什么场景使用这项能力。

换句话说，OpenAPI 主要回答“这个接口怎么调用”，ACC 尝试回答“这个能力是否适合交给 Agent，以及应当带着什么治理信息交给它”。

为什么不把所有治理能力都塞进契约？

第一次看到 ACC 时，有人可能会觉得它比较薄：为什么不直接把租户隔离、审批人、工作时间、事务编排、回滚策略、数据保留期限等能力全部写进去？

后来认真推演会发现，这种克制恰恰很重要。

租户隔离最终应该由业务系统的数据和权限层强制；审批人取决于企业自己的组织结构；事务和补偿属于工作流或 Saga；审计保留期限属于企业合规策略。

如果把这些内容全部写进一份通用契约，它很快就会变成某个具体产品的配置文件，而不是能够被不同语言、框架和运行时共同采用的开放语义。

ACC 关注的是“声明什么”，运行时负责“如何执行”，业务系统仍然保留最终授权权。

这也是一个很重要的边界：

Agent 可以获得触达业务能力的机会，但最终权限仍然属于业务系统。

ACC 与 MCP 并不冲突

MCP 解决的是工具如何被暴露、发现和调用的问题。

ACC 关注的是这些工具进入真实业务后，如何附带业务范围、主体要求、风险、审批和审计等治理信息。

两者并不是替代关系。

一个业务接口可以通过 MCP、HTTP、SDK 或其他方式提供给 Agent，同时使用 ACC 声明它的业务治理属性。传输协议负责连接，能力契约负责表达边界。

一个简单的例子

x-agent-capability:
  version: 1
  enabled: true
  scope: refund.create

  subject:
    required: true

  risk:
    level: high

  approval:
    required: true

  audit:
    sensitive: true

  execution:
    readonly: false
    idempotent: true

  guidance:
    when_to_use: 当用户明确要求为已支付订单创建退款时使用
    returns: 返回退款申请编号和当前处理状态

这段声明不会替业务系统完成退款，也不会绕过原有权限。

它只是让不同 Agent 运行时能够用共同的方式理解：这是一项退款能力，需要可信主体，风险较高，具有审批意图，需要注意敏感审计，并且调用应当具备幂等性。