从信息工具到行动代理，Agent 带来的真正变化，不只是软件获得了更自然的交互方式，而是人类开始把一部分行动过程委托给机器。技术能力向前走了一步，授权、责任与治理秩序也必须随之向前。
假设有一天，你对一个 Agent 说：
把今天重复支付的订单找出来，符合条件的直接发起退款。
如果它只是生成一段操作建议，我们面对的仍然是一个信息质量问题。答案可能正确，也可能错误，但在结果进入现实系统之前，通常还有一个人负责阅读、判断和执行。
如果它真的查找订单、判断条件、调用退款接口，并改变了账户余额，事情就完全不同了。
此时，Agent 产生的不再只是一段文本，而是一个现实后果。
我们必须开始追问：
- 它为什么可以看到退款能力？
- 它正在代表谁行动？
- 谁授权它执行到这一步？
- 哪些情况必须停下来等待人工决定？
- 如果参数在审批后发生变化，原来的批准是否仍然有效？
- 如果执行错误，谁能够解释当时发生了什么？
最终责任应当落在模型、运行时、业务系统，还是发起操作的人身上？
这些问题不会因为模型更聪明而自动消失。恰恰相反，Agent 越能自主完成工作，这些问题就越重要。
这篇文章想讨论的，不是某个产品如何实现工具调用，也不是某份规范是否会在短期成为行业标准。我们真正想讨论的是一个更长远的问题：
当机器开始代表人类进入真实业务系统行动，整个社会是否需要一套关于机器行动边界的共同语言？
一、历史真正改变的，不是 AI 会调用 API
人类一直在把工作交给机器。
计算器替我们完成计算，数据库替我们保存记录，搜索引擎替我们查找信息，传统自动化程序按照预先写好的规则执行任务。这些技术同样会影响现实，但它们的行为通常有清晰、确定的程序边界。
Agent 带来的变化，在于它开始参与过去由人完成的中间过程：
理解模糊意图 ↓ 选择完成目标所需的能力 ↓ 生成调用参数 ↓ 根据结果决定下一步行动 ↓ 持续执行，直到目标完成我们不再只是让软件执行一条明确命令，而是在向它描述一个目标，然后允许它参与决定“接下来应该做什么”。
这里需要避免一种夸大：软件参与判断并不是从 Agent 才开始。算法交易、自动风控、工业控制和推荐系统早已能够根据输入做出选择，并产生现实后果。
Agent 真正放大的，是这种委托的通用性、开放性和动态性：人可以用自然语言描述目标，模型再跨越多个工具和系统选择行动路径；它面对的任务、参数和下一步操作，不再都由开发者预先枚举。
这形成了一种范围更广、链路更长的委托关系。
从技术上看，它表现为模型推理、工具选择和 API 调用；从社会运行角度看，它意味着机器开始进入人类原有的行动链条。
本文所说的“代表人行动”，不是把 Agent 当作新的法律人格，而是描述一种技术事实：它接受人的目标，在运行时中选择操作，并以某个业务主体的上下文向系统发起请求。模型不会因此自动成为责任主体，组织也不能把最终责任转移给模型。
过去，人使用软件完成业务操作：
人登录系统 → 人理解页面 → 人选择操作 → 系统校验权限 → 业务结果产生现在，中间多了一个能够理解意图并代替人选择行动路径的 Agent：
人提出目标 ↓ Agent 解释意图、选择能力、组织参数 ↓ 运行时发起调用 ↓ 业务系统校验并产生结果这条链路看似只是增加了一个技术组件，实际上却改变了责任形成的方式。
当一个人点击“退款”按钮时，我们很容易说明是谁做了什么；当一个 Agent 根据一句自然语言，自主选择退款工具并生成金额时，行动背后同时存在发起者、模型、运行时、工具提供方和业务系统。
参与者增加了，责任却不能因此变得模糊。
二、Agent 时代最稀缺的，可能不是能力，而是可解释的委托
今天的行业非常擅长让 Agent 获得更多能力。
我们在不断改进模型推理，提供更多工具，建设更强的工作流，让 Agent 能连接数据库、浏览器、代码仓库、企业应用和现实设备。
但“能做”只是问题的一半。
另一半是：
一个组织怎样才能清楚地说明，它把什么能力、在什么边界内、以什么责任条件委托给了 Agent？
这不是单纯的安全技术问题，也不是一句“操作前让用户确认”就能解决的问题。
真正可解释的委托，至少应当回答：
能力边界：Agent 最多能够接触哪些业务能力；
- 行动主体：它代表的是匿名访客、登录用户、企业员工还是服务账号；
- 后果等级：这项操作最坏的合理后果是什么；
- 人工介入：哪些行动可以直接继续，哪些行动必须等待外部决定；
- 执行约束：操作是否只读、是否幂等、是否需要限流；
责任记录：行动经过了哪些判断，提交了什么参数，最终产生了什么结果。
这些信息的意义，不只是帮助 Agent“更懂工具”。它们是在为一次机器行动建立可被人类理解和追溯的责任上下文。
一个成熟的 Agent 生态，不能只让机器知道“这个接口怎么调用”，还要让组织能够说明“为什么允许它调用到这里”。
三、现有协议栈解决了连接，却没有自动生成治理秩序
今天的 Agent 技术生态并非一片空白。
OpenAPI 可以描述 HTTP 接口、参数和响应；MCP 等协议可以帮助 Agent 发现和调用工具；Agent 框架和工作流引擎可以组织任务；API Gateway 可以执行鉴权、限流和路由；业务系统掌握真实用户、数据状态和最终权限。
每一层都在解决重要问题。
但把这些组件连接起来，并不会自动生成一套完整的行动治理秩序。
OpenAPI：这个接口的语法是什么？ 工具协议：Agent 如何发现并调用它？ Agent Runtime：如何理解目标、选择工具并组织执行？ API Gateway：请求如何进入系统，流量策略如何执行？ Business System：这个主体此刻究竟有没有权做这件事？这组问题也不是从既有安全体系之外凭空出现的。Capability-based security 长期讨论权力如何被授予和传递；RBAC、ABAC 与 XACML 讨论主体、资源、操作和环境如何形成授权决策；OPA、Cedar 等策略系统则帮助组织把本地授权逻辑从业务代码中分离出来。
它们与 Agent 能力契约并不冲突，但回答的问题不同：
| 体系 | 主要回答的问题 |
|---|---|
| RBAC / ABAC / XACML / OPA / Cedar | 在当前组织和上下文中，这个主体是否可以执行这次操作？ |
| API Gateway / Service Mesh | 应当在流量入口执行哪些认证、路由、限流或策略？ |
| Agent 能力契约 | 一个业务能力面向 Agent 暴露时，应携带哪些可移植、可机器读取的治理声明？ |
| 业务系统 | 根据实时业务事实，这次操作最终是否有权执行？ |因此，公共契约不应重新发明一门授权语言。运行时完全可以把契约声明映射到 OPA、Cedar 或企业自己的策略系统，但私有角色、实时数据和最终授权仍然留在部署方与业务系统中。
同样需要澄清：这里的
scope是面向治理与策略匹配的能力标识，不是 capability security 中能够直接传递权限的不可伪造 capability。二者可以相互启发，却不能被简单画上等号。在这些问题之间，还存在一组相对稳定、却经常散落在各处的信息：
这项业务能力是否允许向 Agent 暴露？ 它的风险大致属于什么等级？ 是否必须绑定一个可信业务主体？ 是否存在人工审批意图？ 是否涉及敏感审计信息？ 执行时有哪些基本约束？现实中的团队通常不是没有处理这些问题，而是把答案分别放在了提示词、平台配置、网关插件、审批代码、日志模块和开发文档里。
这在一个小规模项目中完全可以工作。
但当一个业务系统同时服务多个 Agent、多个入口、多个模型和多个运行时，碎片化的代价就会逐渐显现：同一个退款能力在不同平台中有不同风险描述，同一个审批条件被维护了多份，模型迁移后没人能确认治理配置是否完整迁移，安全人员也无法从接口契约中直接看到 Agent-facing 的能力边界。
问题不是行业完全没有治理，而是治理缺少公共语义。
四、一个问题被准确命名之后，才可能成为公共知识
技术史上，很多重要进步并不是从发明一个庞大系统开始的，而是从准确识别一个反复出现的问题开始。
在问题没有名称时，每个团队都会把它当成自身项目中的特殊情况：
有人把它称为“AI 接口安全”；
- 有人把它归入“工具权限”；
- 有人把它写成“Agent 网关规则”；
- 有人把它放进“工作流审批”；
有人干脆认为这只是提示词工程的一部分。
这些说法都碰到了真实问题的一部分，却很难让产品经理、开发者、安全团队和架构师围绕同一个对象展开讨论。
当我们把“Agent 进入存量业务系统、代表真实主体产生业务结果”单独识别为一种场景，并把它称为 A2B，Agent-to-Business，变化并不只在于多了一个缩写。
它让一类分散问题有了共同讨论对象：
A2B 不是让模型多连接几个 API，而是让 Agent 在可授权、可治理、可追溯的前提下进入真实业务系统行动。
一旦问题被命名，我们才能进一步讨论它需要哪些基础语义、哪些责任属于运行时、哪些责任必须留在业务系统，以及哪些内容有可能形成跨实现的公共契约。
命名不是为了制造术语，而是为了减少整个行业反复解释同一类问题的成本。
五、公共契约的价值，不是让所有实现变得相同
提到标准或契约，人们很容易联想到一种强制统一：所有人使用同一种产品、同一套平台、同一个执行流程。
但真正有生命力的公共标准，往往不是统一所有内部实现，而是在异构系统之间建立最小共识。
HTTP 没有规定网站必须使用哪一种语言开发；OpenAPI 没有规定服务端必须使用哪一种框架；一种 Agent 能力契约同样不应该规定企业必须使用哪一种模型、审批系统、身份平台或数据库。
它真正需要稳定下来的，是不同参与者之间必须共同理解的那一小部分语义。
这可以借用互联网架构中经典的“薄腰”（thin waist / hourglass）结构来理解：
不同模型、Agent、交互渠道和编排框架 ↓ 一组稳定、可机器读取的治理语义 ↓ 不同网关、运行时、审批系统和业务系统上层可以快速创新，下层可以保留企业自身复杂性，中间只维持足够小、足够稳定、能够跨实现成立的共同语言。
公共契约的目标不是消灭差异，而是让差异仍然能够协作。
六、最重要的边界：可触达不等于有权限
任何关于 Agent 行动治理的公共思想，都必须守住一条基础边界：
治理契约管理 Reach：Agent 最多可以触达哪些能力。 业务系统掌握 Authority：这个主体此刻究竟能不能执行。这两个问题看起来接近，实际上不能混为一谈。
“退款申请是一个高风险能力，并且调用时必须绑定可信主体”，是一项相对稳定、可以跨运行时理解的声明。
但“当前员工能不能为这个订单退款 5000 元”，依赖的是实时业务事实：员工属于哪个组织，订单归属谁，订单当前是什么状态，可退款余额还剩多少，企业内部风控是否允许。
这些答案只有业务系统能够权威掌握。
无论 Agent 运行时做了多少治理，业务系统都不能放弃最终授权。因为任何中间层都有可能配置错误，也可能被绕过；真正的数据隔离、权限校验和业务规则必须在所有调用路径上成立。
这条分界的社会意义在于，它阻止我们把机器的“理解”误认为组织的“授权”。
模型可以判断用户想做什么，却不能仅凭判断就获得做这件事的权力。
把这条边界放回退款场景
假设员工让 Agent 为订单发起 5000 元退款，一条完整链路可以这样分工：
- OpenAPI 描述
order_id、amount等请求参数和响应结构； - Agent 能力契约 声明退款能力是否开放、风险等级、是否要求可信主体、何时表达人工审批意图，以及基本审计和执行约束；
- Agent Runtime 或控制面 绑定实际操作主体，评估声明，必要时暂停并等待外部决定，同时确保批准证据只对应被审阅的那组参数；
- 企业策略系统 可以继续基于部门、角色和环境做本地决策，但不会因此取代业务校验；
订单系统 最终检查员工权限、订单归属、当前状态、可退款余额和租户隔离，随后决定执行或拒绝，并留下结果证据。
这里没有任何一层单独完成全部治理。公共契约的价值，是让各层在不相互越权的前提下，对同一项 Agent-facing 能力形成稳定分工。
七、薄，并不意味着不完整
第一次看到一份 Agent 能力契约，人们很自然会问：
- 为什么不把具体审批人写进去？
- 为什么不定义完整身份格式？
- 为什么不描述跨接口事务？
- 为什么不规定回滚和补偿？
- 为什么不增加企业审计保存期限？
为什么不直接定义所有动态业务规则？
这些问题都重要，但重要不代表都应该进入公共契约。
具体审批人依赖组织结构，身份解析依赖企业的身份系统，事务与补偿依赖工作流和业务语义，日志保存期限依赖企业合规制度，动态权限依赖实时业务数据。
如果把这些内容全部塞进一个所谓通用标准，它很快就会变成一套没有任何企业能够完整实现的万能策略语言。
更危险的是，一些字段可能制造虚假的安全感。
例如，在声明里写下“跨接口操作是原子的”，并不会自动产生分布式事务；在网关层覆盖一个租户参数，也不能取代业务系统的数据隔离；写下一个跨字段表达式，更不能自动解决数据从哪里来、是否可信、何时失效以及获取失败后怎么办。
克制不是回避问题，而是尊重问题真实所属的层次。
一份公共契约真正的完整性，不在于字段足够多，而在于它定义的每一个字段都能够：
在不同实现中保持一致含义；
- 不依赖某个产品的私有数据库和 UI；
- 不越过业务系统的最终授权；
- 具有明确的失败语义；
- 可以被机器校验和验证；
在版本演进时不因静默忽略而削弱声明者的安全意图。
标准的难度从来不只是增加能力，更在于知道什么不应该进入核心。
八、治理并不是给 Agent 踩刹车
安全治理经常被理解为限制创新：更多规则、更多审批、更多阻力。
但在 Agent 进入真实业务的过程中，情况恰恰相反。
如果一个组织无法解释 Agent 能接触什么、代表谁行动、何时需要人工介入、执行结果如何追踪，它最理性的选择就是不开放高风险能力。
于是大量 Agent 项目会停留在：
回答帮助文档；
- 查询公开信息；
- 生成操作建议；
- 创建不产生后果的草稿；
展示一个看起来聪明的演示。
而真正有价值的企业工作，往往发生在写操作里：修改状态、处理退款、调整库存、创建工单、维护客户、执行审批、跨系统完成任务。
只有当行动边界能够被可靠治理时，企业才可能放心地逐步开放这些能力。
因此，治理不是 Agent 能力的反方向，而是可信委托能够继续扩大的前提。
一个社会能够把多少行动权交给 Agent，最终不只取决于 Agent 有多聪明，也取决于我们能否为机器行动建立多可靠的责任结构。
九、这套思想降低的是全行业的重复试错成本
如果没有公共参考，每一家准备让 Agent 操作业务系统的企业，都要重新回答风险、主体、审批、审计、业务授权和治理归属等问题。优秀团队能够形成可靠方案，但整个行业仍会重复支付同一笔认知成本；经验不足的团队则可能把安全寄托在提示词或某一个中间层上。
一套公开的治理元模型，即使没有被原样采用，也可以成为参考基线。企业可以直接实现、在内部契约中借鉴，或者公开质疑并提出更好的方案；重要的是，后来者不必从完全空白的问题空间重新开始。
把私人项目中的经验，转化为任何人都能阅读、批评和改进的公共知识，本身就是开源标准最朴素的社会价值。
十、未来的生态不会只有一个入口
未来的 Agent 生态大概率仍然是多元的：企业会同时使用不同模型、Agent 平台、云服务和执行器；治理能力也可能出现在独立控制面、API Gateway、Agent 平台或业务系统内部。
如果治理语义只存在于某个平台内部，更换平台和复用业务能力就会产生大量重复配置。中立契约的价值，不是争夺运行时位置，而是让不同产品可以围绕同一份声明工作：
它可以通过 OpenAPI 扩展被描述； 可以通过 MCP 或其他协议被传递； 可以由 Agent 平台读取； 可以由 API Gateway 执行部分策略； 可以由独立控制面落实治理； 最终由业务系统完成权威校验。实现形态可以竞争，基础问题却可以共享。
十一、如何评价一份仍在早期的公共规范
一套新思想刚刚出现时，人们最容易用当前数字衡量它：有多少用户、多少实现、多少下载、多少企业接入。
这些指标当然重要，因为没有实践的标准无法证明自身价值。
但对于仍处在问题定义阶段的公共规范，还要看它是否识别了一个反复出现的问题，建立了共同词汇，划清了责任边界，并提供了可验证、可争论、可继续演化的公共起点。
这些条件只能证明它值得继续验证，不能代替采用数据、独立实现和生产经验。我们不应把“具备长期研究价值”“形成事实标准”和“成为唯一标准”混为一谈；后两者必须由生态协作和真实运行共同证明。
十二、ACC 是这套思想的一次公开范式实践
在这样的背景下，ACC，Agent Capability Contract 的位置才变得清楚。
ACC 不是这篇文章的前提，也不是关于未来的唯一答案。它是对上述问题的一次公开、可机器读取、可验证的范式实践。
它尝试做几件事：
- 用 A2B 描述 Agent 安全、可治理地进入已有业务系统工作的场景；
- 把能力边界、风险、主体、审批意图、审计和执行约束提炼为公共语义；
- 坚持 Reach 与 Authority 分离，让业务系统保留最终权限；
- 保持核心足够薄，使声明不绑定特定模型、平台、网关或审批产品；
通过 Schema、Conformance 和公开治理，让不同实现能够围绕同一份契约讨论一致性。
当前 ACC 选择通过 OpenAPI 扩展
x-agent-capability提供首个正式绑定，但这不意味着这种思想只能存在于 OpenAPI 中。未来它可以拥有其他绑定，也可能被新的协议和实现吸收。真正重要的不是某个字段是否永远保持不变，而是它背后的基础命题是否成立：
Agent 的能力需要显式开放，而不是默认拥有； 模型不能成为安全决策的唯一依据； 代理行动需要绑定可追溯的责任上下文； 高风险行动需要可声明的人工介入意图； 治理元数据必须与模型生成参数分离； 业务系统始终保留最终授权。如果这些命题能够帮助行业更清楚地思考机器行动，ACC 就已经不只是一份 Schema。
它是一种关于 Agent 如何进入现实业务秩序的设计提案。
十三、我们也必须诚实地承认它的边界
把视角拉高，并不意味着应该夸大结论。
ACC 目前不是全球事实标准，也不能仅凭一套自洽设计就宣布行业已经完成共识。它仍然需要更多独立实现、真实业务案例、跨平台绑定、社区提案和长期兼容性验证。
它也不会解决企业 Agent 落地中的全部问题：
- 不替代业务系统的身份和权限体系；
- 不承担最终租户隔离；
- 不定义完整审批组织结构；
- 不代替 Workflow 或 Saga 协议；
- 不承诺跨接口事务；
- 不决定企业合规与日志保留制度；
不把所有动态业务规则变成通用表达式。
这些边界并不削弱它的价值。
相反，能否长期保持中立，取决于它是否抵抗住“把所有重要问题都塞进核心”的诱惑。
一个标准只有清楚自己不负责什么，别人才能放心地围绕它建设各自的实现。
十四、即使未来不叫 ACC，这组问题也不会消失
未来，Agent 行动治理可能以不同形式进入产业基础设施：
成为独立开放契约；
- 成为工具协议中的治理扩展；
- 成为 API Gateway 和 AI Gateway 的标准能力；
- 成为 Agent 平台之间可交换的元数据；
- 成为企业业务系统原生支持的一组声明；
或者形成一个今天还没有名字的新标准。
名称、字段和承载方式都可能改变。
如果 Agent 继续从“生成内容”走向“代表人执行更多业务行动”，行业就必须更系统地回答同一组问题：它能做什么、代表谁、在什么边界内行动、何时需要人类介入、如何留下责任证据，以及最终由谁授权。
因此，我们真正希望推动的，不是让所有人接受某个缩写，而是让这组问题尽早成为公共议题。
当越来越多团队开始用共同语言讨论机器行动的边界，当开发者不再默认“接通工具就等于可以安全执行”，当产品经理、安全人员和业务负责人能够围绕同一组治理命题协作，行业就已经向前走了一步。
结语：智能越向前，责任结构越不能留在身后
人类创造工具，是为了把能力延伸到自身之外。
从机械装置到软件系统，从自动化程序到今天的 Agent，能力边界的扩展往往伴随着新的规则、责任和协作方式。
Agent 时代真正值得期待的，不是机器可以毫无边界地替人行动，而是我们能够建立一种成熟的委托关系：机器获得足够的能力完成工作，同时每一次重要行动仍然处在人类可以授权、约束、解释和追溯的秩序中。
历史不会因为一份规范发布就自动选择它。
当 Agent 进入更多高后果业务，无法解释责任、无法建立信任的架构会越来越难被组织采用。
ACC 是否会成为最终名称，今天没有人能够断言。如果机器代理业务行动的规模持续扩大，关于能力边界、行动主体、风险、人工介入和责任记录的共同语义，就会逐步成为产业基础设施需要解决的问题。
评判这套思想的价值，不应只看今天有多少企业原样采用某份规范。
更应该看未来，当行业讨论 Agent 如何安全进入真实世界时，是否仍然绕不开它所提出的那些基础问题。
机器能够走多远，取决于智能；人类敢让它走多远，取决于治理。
延伸阅读：
