从 0 到 1：如何让 Agent 安全接入并操作一套存量业务系统- 惊觉

从 Function Calling、MCP、Agent 平台和 API Gateway 一路推演，我们最终缺少的究竟是什么？

假设你是一名普通开发者，手里维护着一套已经稳定运行多年的业务系统。

它可能是一套 SaaS 商城，也可能是 CRM、ERP、工单系统、财务系统、门店后台或者企业内部管理平台。系统里已经有成熟的用户体系、权限模型、业务 API、数据库和操作后台。每天都有真实用户在里面查询订单、调整库存、处理退款、维护员工和修改配置。

某一天，产品经理找到你：

现在 Agent 发展得这么快，我们也给系统接入 AI 吧。以后用户不必到处点菜单，直接说一句“查一下今天的退款订单”或者“把这个商品下架”，系统就能替他完成。

这听起来像一个大模型接入需求。

找一个模型，做一个聊天窗口，再给模型几份接口文档，似乎就可以开工了。

但如果我们真的按照工程落地的顺序往下走，很快会发现：这件事最困难的部分，可能从来都不是“如何调用大模型”。

真正困难的是，当 Agent 从回答问题走向操作真实业务数据时，我们如何让它始终待在一个可信、可治理、可追溯的边界里。

这篇文章不预设某个产品是答案。我们从一个存量业务系统的实际改造开始，把可能采用的技术方案逐层摆出来，看看问题最终会收敛到哪里。

1. 第一版需求：先做一个能回答问题的助手

最初的需求往往比较温和。

用户希望问：

今天有多少笔订单？
退款流程应该怎么走？
商品审核有哪些规则？
某个功能应该在哪里配置？

这一阶段，典型架构是：

用户问题
  ↓
聊天界面
  ↓
大模型 + 知识库检索
  ↓
生成回答

模型读取帮助文档、业务规则和知识库，再把答案整理给用户。即使回答不准确，风险通常也停留在“内容质量”层面。用户仍然需要进入业务后台，亲自完成最终操作。

这类场景适合用聊天机器人、RAG 或企业知识库来解决。

可业务方很快会提出下一步需求：

既然它已经知道退款流程，为什么不能直接帮我创建退款申请？

从这一刻开始，问题发生了根本变化。

过去，模型只生成文本；现在，模型要产生真实业务结果。

2. 第二版需求：给模型几把“工具”

为了让模型真正办业务，我们可以把现有 API 包装成 Function Calling 工具：

order.query          查询订单
product.offline      下架商品
refund.request       创建退款申请
staff.delete         删除员工

模型根据用户意图选择工具、生成参数，应用程序负责调用对应接口。

架构变成了：

用户请求
  ↓
Agent 判断意图
  ↓
选择工具并生成参数
  ↓
调用业务 API
  ↓
返回业务结果

从演示效果看，这一步已经非常接近“Agent 操作业务系统”。

但只要把几个工具放到真实环境里，新的问题就会迅速出现。

2.1 查询和退款显然不是同一种操作

“查询今天的订单”和“为订单退款 5000 元”都可以表现为一次工具调用，但它们的后果完全不同：

操作	业务后果	初步判断
查询订单	不改变业务状态	低风险
修改商品描述	修改单个业务对象	中风险
下架商品	影响商品销售状态	中风险
创建退款	涉及资金和售后流程	高风险
删除员工	可能影响账号、权限和组织数据	高风险
批量通知客户	影响大量外部用户	高风险

如果把所有工具都平等交给模型，风险边界就只剩下模型是否“足够聪明”。这显然不能成为生产系统的安全基础。

2.2 模型知道参数，不等于它有权操作

假设 Agent 正确生成了：

{
  "order_id": "ORD-20260714-001",
  "amount": 5000
}

这组参数格式完全正确，但业务系统仍然需要回答：

当前用户是不是这个订单所属门店的员工？
这个员工是否有退款权限？
订单当前状态是否允许退款？
可退款余额是否还够？
是否存在重复退款申请？

这些答案不在模型里，也不应该由模型决定。

只有业务系统掌握实时订单状态、用户权限、租户边界和资金规则。无论 Agent 多强，最终授权都必须留在业务系统。

2.3 提示词不是治理规则

一种常见做法是在系统提示词里写：

退款前必须征得用户确认。
不要删除管理员账号。
金额超过 1000 元时必须谨慎操作。

这些提示对模型行为有帮助，却不能充当安全边界：

提示词可能被上下文干扰；
不同模型可能产生不同理解；
工具规则无法被机器独立校验；
审计系统无法证明当时究竟执行了哪条规则；
Agent 升级或迁移后，原来的提示不一定继续生效。

治理规则可以被模型理解，但不能只依赖模型自觉遵守。

到这里，我们得到第一个工程结论：

Function Calling 解决了“模型如何调用接口”，但没有完整回答“这个接口是否应该被 Agent 调用，以及调用时必须经过哪些治理步骤”。

3. 第三版需求：用 MCP 统一工具连接

继续往下做，我们很自然会考虑 MCP。

MCP 提供了 Agent 与工具之间的标准连接方式。工具可以声明名称、描述、输入 Schema 和输出结构，客户端可以发现并调用这些工具。相比每个模型厂商各自维护一套 Function Calling 适配，MCP 显著降低了连接成本。

当前 MCP 规范也提供了 readOnlyHint、destructiveHint、idempotentHint、openWorldHint 等工具注解，用来向客户端提示工具是否只读、是否可能产生破坏性影响、是否幂等，以及是否会接触开放世界。

但 MCP 规范同时明确说明：这些 Tool Annotations 是 hint，不保证一定忠实描述工具行为；如果注解来自不可信服务器，客户端不能仅凭这些注解决定是否调用工具。MCP 官方在一篇关于工具注解与风险词汇的文章中也专门讨论了这种边界。换句话说，MCP 已经开始提供基础风险词汇，但提示本身不等于可信治理契约。

这并不是 MCP 的缺陷，而是它的职责边界。MCP 优先解决的是：

工具如何被发现；
参数如何描述；
调用如何发起；
结果如何返回；
Agent 与工具如何减少平台间适配。

企业业务操作仍然要额外回答：

谁确认这份风险声明来自可信来源？
哪些业务场景可以向 Agent 暴露这个工具？
调用是否必须绑定一个真实业务主体？
哪些参数会触发人工审批意图？
审批通过后，如何确认执行参数没有发生漂移？
调用结果如何进入企业审计和追踪链路？

于是第二个结论出现了：

MCP 可以成为 Agent 调用业务能力的重要连接协议，但“连接得到”依然不等于“治理完成”。

更合理的方向不是让治理契约与 MCP 竞争，而是让治理语义可以通过 MCP、OpenAPI 或其他绑定方式被运行时读取。

4. 第四版需求：直接使用 Agent 平台

既然从零实现会遇到这么多问题，使用 Dify、Coze 或其他 Agent 平台会不会更简单？

答案是：在很多场景下，确实会简单很多。

Agent 平台通常已经提供：

模型接入；
提示词和变量管理；
工作流编排；
Tool 插件；
知识库；
对话应用；
人工输入或暂停节点；
应用发布和运行环境。

例如，Dify 的 Tool Plugin 可以把第三方服务封装成 Agent 和 Workflow 可调用的工具，Human Input 能在工作流中暂停执行并等待人工动作。这些能力能够快速完成一个具体 Agent 应用。

但如果企业不只有一个 Agent 应用，新的问题又会出现。

假设同一个退款接口需要同时服务于：

一个 Dify 工作流；
一个网页内嵌 Agent；
企业微信里的业务助手；
一个本地运行的 Codex、Claude Code 或 OpenClaw 执行器；
未来可能更换的另一个 Agent 平台。

如果风险、主体、审批和执行约束全部写在某个平台的私有配置里，那么每增加一个运行时，就要重新配置一次。时间久了，企业会拥有多份内容相似、语义却不完全一致的治理规则。

Agent 平台非常适合构建和编排 Agent，但业务系统自身的能力边界，最好不要只存在于某个 Agent 产品内部。

这带来第三个结论：

Agent 平台可以负责“如何组织一次 Agent 应用”，但业务能力提供方仍然需要一份不依赖某个平台的能力声明。

5. 第五版需求：把治理交给 API Gateway

接下来，我们还可以考虑 API Gateway。

网关本来就位于调用方与业务 API 之间，通常已经具备：

路由；
身份认证；
限流；
请求转换；
日志；
指标；
访问控制。

在这里增加 Agent 治理插件，是一条非常现实的产品路径。事实上，一些 AI Gateway 已经开始同时处理 LLM、MCP 和 Agent 流量。

但传统 API Gateway 更擅长理解一次网络请求，而 Agent 业务操作还可能涉及：

当前请求属于哪一次 Agent 任务；
Agent 代表哪个业务主体；
哪组参数触发了审批；
审批结果与最终执行参数是否一致；
长任务如何排队、恢复和送达；
本地执行器或异步业务任务如何接入；
会话、工具调用和业务结果如何形成同一条追踪链路。

因此，API Gateway 可以是治理策略非常重要的执行位置，也可能成长为完整 Agent 控制面的宿主。但无论这层能力部署成独立服务、网关插件还是云厂商托管能力，它都仍然需要一套明确的 Agent-facing 治理语义。

我们真正缺少的，不一定是又一个固定形态的产品；更可能是一份能够被不同产品共同理解的契约。

6. 到这里，我们到底在做什么？

项目进行到这个阶段，团队内部往往会遇到一个有意思的沟通问题。

产品经理说：

我们要给业务系统接入 AI。

开发者可能理解为接入模型 API。

算法团队可能理解为增加 RAG 和工具调用。

业务人员可能理解为做一个聊天机器人。

安全团队可能理解为开放一批受控 API。

架构师可能理解为增加 Agent 平台、MCP Server 或 API Gateway。

这些理解都触及了问题的一部分，却没有准确描述正在发生的完整变化：

一个 Agent 正在代表真实业务主体，进入一套已经存在的业务系统，读取数据、改变状态，并触发真实业务结果。

如果每次讨论都要重复这一整句话，沟通成本会很高。我们需要一个更短、更精确的词来指代这类场景。

在这篇文章里，我们把它称为 A2B，Agent-to-Business。

A2B 不是一个具体产品，也不是另一个传输协议。它描述的是一类工程场景：

A2B = Agent 安全、可治理地通过已有业务系统完成真实业务工作。

它与普通聊天机器人的区别在于，结果不再止于一段文本；它与普通机器到机器 API 调用的区别在于，调用路径中存在模型推理、工具选择、代理主体和不确定性；它与传统 RPA 的区别在于，Agent 会根据语义和上下文动态选择业务能力。

一旦这个场景被单独命名，问题会清晰很多：

模型和 Agent 负责理解意图；
MCP、HTTP 或 SDK 负责连接和调用；
Agent 平台负责应用编排和运行；
API Gateway 可以负责流量入口与部分策略执行；
业务系统负责最终权限与业务规则；
中间还需要一层可移植的能力治理语义。

7. A2B 真正需要回答的六类问题

重新审视前面的商城系统，我们会发现，不同业务操作虽然差异很大，但都在反复追问同一组问题。

7.1 Agent 可以触达什么？

业务系统里可能有数百个 API，但不应该全部暴露给 Agent。

同一个 refund.request.create 能力，也未必应该在所有路由、渠道和业务场景中可见。客服助手、财务助手和门店助手需要的能力范围可能完全不同。

这是能力的触达边界。

7.2 操作后果有多大？

查询、创建草稿、修改状态、发起资金操作和删除数据，需要不同的治理强度。

模型需要知道工具的基本风险，运行时也需要在调用前应用相应策略。

7.3 是否必须绑定真实业务主体？

有些公共查询可以匿名执行；但查询企业订单、修改商品或创建退款时，运行时必须知道 Agent 正在代表谁。

主体可以来自登录会话、JWT、签名票据、企业身份系统或服务账号。具体身份格式不必统一，但“这个能力是否要求可信主体”可以被统一声明。

7.4 什么时候需要人工介入？

某些操作每次都需要审批，另一些操作只在特定参数条件下需要人工介入。

例如：

退款金额 <= 1000 元：可以按本地策略处理
退款金额 > 1000 元：创建审批意图

这里声明的是审批意图，而不是强行规定每家企业使用什么审批系统、由谁审批或者界面长什么样。

7.5 哪些信息需要进入审计？

一旦 Agent 可以产生业务结果，企业需要能够回答：

谁发起了这次操作；
Agent 选择了什么能力；
当时提交了哪些参数；
为什么进入审批或被拒绝；
业务系统返回了什么结果；
整条链路是否可以追踪。

如果参数或响应可能包含敏感信息，运行时还需要采取保守的审计策略。

7.6 执行本身有什么约束？

运行时至少需要知道：

操作是否只读；
是否幂等；
超时时间；
调用频率限制；
Agent 应该在什么情况下使用这个能力；
结果大致代表什么。

到这里，我们已经不是在讨论某个模型或某个 Agent 平台，而是在讨论业务能力进入 Agent 世界之前，应当附带哪些稳定、可机器读取的治理信息。

8. 如果没有共同契约，会发生什么？

企业当然可以不引入任何新标准，直接在现有系统里完成这些工作。

第一版可能是：

风险等级写在提示词里
工具白名单写在 Agent 平台里
审批条件写在网关插件里
主体映射写在业务中间件里
超时和限流写在另一份配置里
审计规则藏在日志代码里

只维护一个 Agent、几个工具时，这种方式完全可以运行。

问题会在系统扩大后逐渐出现：

同一个业务能力在不同 Agent 平台里有不同描述；
模型迁移时无法确认治理配置是否完整迁移；
API 作者不知道哪些接口已经被 Agent 使用；
安全团队无法从接口契约中直接审查风险；
运行时无法区分可信治理元数据和模型生成参数；
每个业务团队都重新发明一套字段、默认值和解释方式。

最终，企业仍然会拥有一份“能力契约”，只是它可能是隐式的、分散的、产品私有的，而且无法被其他实现复用。

所以真正的问题不是“要不要契约”，而是：

这份契约继续散落在提示词、平台配置和代码里，还是被明确地写在业务接口旁边，并用开放方式供不同运行时读取？

9. 从问题自然收敛到 ACC

沿着前面的工程问题继续收敛，我们需要的契约至少应当满足几个条件：

不绑定某个模型厂商；
不绑定某个 Agent 平台；
不强制使用 MCP、HTTP 或某种 SDK；
可以与标准 API 描述放在一起；
可以被机器校验；
能声明 Agent-facing 治理事实；
不取代业务系统的最终授权；
不把整个审批、身份、工作流和合规体系塞进一份接口声明。

这就是 ACC，Agent Capability Contract 想解决的问题。

ACC 是一套开放的 Agent 能力声明契约，用来描述业务系统可以把哪些业务能力开放给 Agent，以及这些能力在 Agent-facing 运行时中应当如何被治理。

它不是 Agent 平台，不运行模型，不调用接口，也不替代业务系统。它只定义能力声明。

ACC v1 的核心字段，与前面的工程问题基本一一对应：

工程问题	ACC 声明
这个操作是否对 Agent 开放	`enabled`
它代表哪项稳定业务能力	`scope`
最坏的合理后果是什么	`risk`
是否要求可信业务主体	`subject`
是否存在审批意图或参数条件	`approval`
参数或响应是否可能包含敏感信息	`audit`
是否只读、幂等、超时和限流	`execution`
Agent 何时应该使用、会返回什么	`guidance`

这不是从字段清单出发设计一个格式，而是从真实 A2B 接入过程中反复出现的问题，向下提炼出最小公共语义。

10. 一个退款接口如何增加 ACC 声明

ACC v1 的首个正式绑定是 OpenAPI 扩展字段 x-agent-capability。

下面是一个经过简化的退款申请接口：

paths:
  /refund-requests:
    post:
      operationId: refund_request_create
      summary: Create a refund request for an order.
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required: [order_id, amount]
              properties:
                order_id:
                  type: string
                amount:
                  type: number
                  minimum: 0

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

        risk:
          level: high

        subject:
          required: true

        approval:
          when:
            - param: amount
              op: ">"
              value: 1000
              label: Refund amount exceeds 1000.

        audit:
          sensitive: true

        execution:
          readonly: false
          idempotent: true
          timeout_ms: 10000
          rate_limit:
            count: 10
            window: 1m

        guidance:
          when_to_use: Use when a user requests a refund for an existing order.
          returns: Returns the created refund request and its current status.

标准 OpenAPI 继续描述接口路径、请求参数和数据类型；ACC 只补充 Agent-facing 治理语义。

一个兼容运行时读取后，可以知道：

这项能力已经显式允许向 Agent 暴露；
它的稳定能力范围是 refund.request.create；
这是高风险操作；
没有可信主体时，不应向 Agent 展示或调用；
金额超过 1000 时应创建审批意图；
参数或响应可能包含敏感信息；
操作不是只读，但声明为幂等，并带有超时与限流提示。

随后，业务系统仍然必须检查：

当前主体有没有退款权限；
订单是否属于当前组织或门店；
当前状态是否允许退款；
可退款金额是否足够；
是否违反真实业务规则。

这两层不能混为一谈。

11. 最关键的架构边界：Reach 与 Authority

ACC 的核心边界可以浓缩成两句话：

ACC 管 Reach：Agent 最多可以触达哪些业务能力。
业务系统管 Authority：这个主体此刻到底能不能执行。

为什么不能让 ACC 直接决定所有权限？

因为最终权限依赖实时、私有且高度业务化的数据：

当前用户属于哪个组织；
订单是否归他管理；
账户是否被冻结；
合同状态是否有效；
库存是否足够；
可退款余额是多少；
当前请求是否命中企业内部风控规则。

这些判断必须在业务系统内部成立，即使有人绕过 Agent 运行时直接调用 API，业务系统也不能失去安全边界。

ACC 能够标准化的是更稳定的 Agent-facing 事实：

能力是否允许暴露；
使用什么 scope；
风险等级；
是否要求可信主体；
是否声明审批意图；
是否涉及敏感审计；
基本执行提示。

这种分离既避免把最终授权交给模型，也避免把 ACC 膨胀成一个无法跨企业复用的万能策略引擎。

12. 为什么 ACC 没有把所有治理能力都塞进去？

第一次看到 ACC 的人，很容易继续追问：

为什么不声明具体审批人？
为什么不规定 JWT、LDAP 或企业微信身份格式？
为什么不把租户隔离字段放进去？
为什么不描述跨接口事务？
为什么不声明回滚和补偿操作？
为什么不规定审计保存七年？
为什么不增加一套通用表达式语言？

这些问题都很重要，但“重要”不等于“应该进入核心契约”。

一个面向不同实现的开放契约，必须保持设计纪律。核心字段至少需要满足：

在不同运行时中具有一致含义；
不依赖某个产品的数据库、UI 或组织结构；
不重复 OpenAPI 和 JSON Schema 已经能够表达的参数结构；
不要求运行时成为最终业务授权方；
可以提供明确的默认值、失败语义和一致性验证；
在版本演进时不会被旧实现静默忽略后降低安全性。

例如，“退款金额不能超过当前订单可退款余额”当然是必要规则。但这里的“当前可退款余额”来自实时业务状态，只有业务系统能够权威获取并校验。把它写成一个看起来通用的表达式，并不会自动解决数据来源、权限、时效和失败语义。

再比如，租户隔离必须由业务系统的数据层和授权层最终强制。仅让 Agent 网关覆盖一个 tenant_id 参数，不能防止其他调用路径绕过隔离。

ACC 保持薄核心，不是因为没有看到这些问题，而是因为它不希望用一个字段制造虚假的安全保证。

准确的分层应该是：

ACC：声明 Agent-facing 能力边界
Runtime：执行暴露、审批意图、审计和调用治理
Business System：完成最终身份、权限、数据隔离和业务规则校验
Workflow / Approval System：兑现组织自己的流程
Transport / Binding：负责 HTTP、MCP、SDK 或消息队列连接

13. ACC 与 OpenAPI、MCP、Agent 平台是什么关系？

ACC 并不试图替代现有技术。

技术或组件	主要职责	与 ACC 的关系
OpenAPI	描述 HTTP API、参数和响应结构	ACC 可通过扩展字段附着在 operation 上
MCP	连接 Agent 与工具，统一发现和调用	可以承载或绑定 ACC 治理语义
Function Calling	让模型选择工具并生成参数	ACC 为运行时补充可信治理元数据
Dify、Coze 等平台	构建、编排和运行 Agent 应用	可以读取或映射 ACC 声明
API Gateway	执行鉴权、限流、路由和流量策略	可以成为 ACC 策略执行位置
业务系统	掌握真实数据、用户和业务状态	始终保留最终 Authority

理想结果不是所有企业都部署同一个产品，而是不同产品可以理解同一份业务能力声明。

未来 ACC 声明可以被独立控制面读取，也可以由 Agent 平台、MCP Gateway、API Gateway、SDK 生成器或业务系统原生模块实现。实现形态可以不同，契约语义保持一致。

14. 从 0 到 1 的落地路线

如果你现在就要给一套存量业务系统接入 Agent，一个更稳妥的顺序是：

第一步：盘点业务能力，而不是盘点页面按钮

把业务系统中真正可复用的操作列出来：

order.read
order.search
product.update
product.offline
refund.request.create
staff.search

不要一开始就把整个后台菜单交给 Agent，也不要把内部管理 API 全量暴露。

第二步：从低风险、只读能力开始

第一批优先选择：

查询订单；
查询商品；
查询库存；
查询工单；
获取经营摘要。

先验证主体传递、接口调用、日志和错误处理，再逐步开放写操作。

第三步：使用合适的连接方式

根据现有系统选择：

已有 OpenAPI：直接增加 ACC 扩展声明；
需要 MCP：把业务能力映射为 MCP Tool，同时保留可信治理来源；
使用 Agent 平台：通过 Tool Plugin 或 HTTP 工具接入；
老系统不方便改造：增加薄适配器、SDK 或本地执行器；
长任务：使用队列、任务认领和异步回传，而不是强行同步等待。

连接方式不是唯一的，关键是不要让治理语义只存在于某个连接实现里。

第四步：为能力补充治理声明

至少明确：

是否允许 Agent 使用；
scope；
风险等级；
是否要求真实主体；
是否存在审批意图；
是否涉及敏感审计；
是否只读、幂等、超时和限流。

第五步：运行时执行治理，业务系统保留最终授权

运行时负责：

根据路由和 scope 筛选能力；
隔离模型输入与可信治理元数据；
检查可信主体；
评估审批条件；
记录调用与结果；
执行限流、超时和任务恢复。

业务系统继续负责：

身份真实性；
用户权限；
数据归属；
租户隔离；
订单和资金状态；
最终业务规则。

第六步：用真实场景做闭环验证

不要只测试“模型是否选对工具”。还要测试：

无主体时能力是否隐藏；
高风险操作是否进入正确治理链路；
字符串 "1000" 是否被错误当成数字 1000；
审批后参数变化是否会被识别；
重复请求是否会造成重复业务结果；
业务系统拒绝操作时，Agent 是否准确返回原因；
每次调用是否能够通过 trace 回看。

第七步：再开放写操作和多入口

完成低风险闭环后，再逐步增加：

商品修改；
工单创建；
退款申请；
员工与权限操作；
网页聊天组件；
企业微信、钉钉、飞书等渠道；
本地 Agent 和执行器。

15. 契约之外，还需要一个运行时

ACC 只声明能力，不负责执行。

真正落地时，团队仍然需要一个运行时来读取声明、连接模型、执行治理、管理审批意图、记录审计和调用业务接口。

这个运行时可以有多种形态：

企业自己开发；
Agent 平台内置；
API Gateway 插件；
云厂商托管服务；
独立部署的 Agent 控制面。

BailingHub（百灵中枢）是一个已经公开的 ACC 开源实现，提供路由、模型与工具接入、主体票据、审批意图、审计追踪、执行器和结果送达等完整控制面能力。

但 ACC 与任何实现保持独立。你可以只使用 ACC，也可以用自己的网关、平台或运行时实现它。未来其他实现同样可以按照公开流程登记兼容性证据。

对于一项希望成为通用契约的规范来说，这种独立性非常重要：

标准不应该要求所有人使用同一个产品；产品应当通过实现标准来证明自己的价值。

16. 回到最初的需求

现在再看产品经理最初的那句话：

给我们的业务系统接入 AI，让用户可以直接说一句话完成操作。

经过完整推演，它实际包含了至少四层工作：

第一层：让模型理解用户意图
第二层：让 Agent 找到并调用业务工具
第三层：让调用处于可声明、可审批、可审计的治理边界
第四层：让业务系统继续掌握最终权限和业务规则

只完成前两层，可以做出非常精彩的演示；只有四层同时成立，才更接近可以进入真实企业环境的 A2B 系统。

当 Agent 开始操作订单、资金、库存、员工和客户数据时，企业事实上已经需要一份能力契约。

区别只在于：

这份契约是隐含在提示词、代码和某个平台的私有配置里；
还是被明确地写出来，接受机器校验，并能够被不同运行时共同理解。

ACC 是对后一条路径的一次开放尝试。

它不试图解决 A2B 世界里的所有问题，也不假设所有实现最终都会长成同一个产品。它只希望先把一件基础而重要的事情说清楚：

当一项业务能力准备开放给 Agent 时，它应当如何声明自己的触达范围、风险、主体要求、审批意图、审计敏感性和执行约束。

如果未来 Agent 真正进入大量存量业务系统，某种这样的能力声明语言，无论最终叫什么，都会逐渐成为工程基础设施的一部分。

从 0 到 1：如何让 Agent 安全接入并操作一套存量业务系统