AI 接上了所有系统:但没有人接过它的责任

假设有一天，你对一个 Agent 说：

如果它只是生成一段操作建议，我们面对的仍然是一个信息质量问题。答案可能正确，也可能错误，但在结果进入现实系统之前，通常还有一个人负责阅读、判断和执行。

如果它真的查找订单、判断条件、调用退款接口，并改变了账户余额，事情就完全不同了。

此时，Agent 产生的不再只是一段文本，而是一个现实后果。

我们必须开始追问：

• 它为什么可以看到退款能力？
• 它正在代表谁行动？
• 谁授权它执行到这一步？
• 哪些情况必须停下来等待人工决定？
• 如果参数在审批后发生变化，原来的批准是否仍然有效？
• 如果执行错误，谁能够解释当时发生了什么？
• 最终责任应当落在模型、运行时、业务系统，还是发起操作的人身上？

这些问题不会因为模型更聪明而自动消失。恰恰相反，Agent 越能自主完成工作，这些问题就越重要。

这篇文章想讨论的，不是某个产品如何实现工具调用，也不是某份规范是否会在短期成为行业标准。我们真正想讨论的是一个更长远的问题：

一、历史真正改变的，不是 AI 会调用 API

人类一直在把工作交给机器。

计算器替我们完成计算，数据库替我们保存记录，搜索引擎替我们查找信息，传统自动化程序按照预先写好的规则执行任务。这些技术同样会影响现实，但它们的行为通常有清晰、确定的程序边界。

Agent 带来的变化，在于它开始参与过去由人完成的中间过程：

理解模糊意图↓选择完成目标所需的能力↓生成调用参数↓根据结果决定下一步行动↓持续执行，直到目标完成

我们不再只是让软件执行一条明确命令，而是在向它描述一个目标，然后允许它参与决定“接下来应该做什么”。

这里需要避免一种夸大：软件参与判断并不是从 Agent 才开始。算法交易、自动风控、工业控制和推荐系统早已能够根据输入做出选择，并产生现实后果。

Agent 真正放大的，是这种委托的通用性、开放性和动态性：人可以用自然语言描述目标，模型再跨越多个工具和系统选择行动路径；它面对的任务、参数和下一步操作，不再都由开发者预先枚举。

这形成了一种范围更广、链路更长的委托关系。

从技术上看，它表现为模型推理、工具选择和 API 调用；从社会运行角度看，它意味着机器开始进入人类原有的行动链条。

本文所说的“代表人行动”，不是把 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 能力契约并不冲突，但回答的问题不同：

因此，公共契约不应重新发明一门授权语言。运行时完全可以把契约声明映射到 OPA、Cedar 或企业自己的策略系统，但私有角色、实时数据和最终授权仍然留在部署方与业务系统中。

同样需要澄清：这里的 scope 是面向治理与策略匹配的能力标识，不是 capability security 中能够直接传递权限的不可伪造 capability。二者可以相互启发，却不能被简单画上等号。

在这些问题之间，还存在一组相对稳定、却经常散落在各处的信息：

这项业务能力是否允许向 Agent 暴露？它的风险大致属于什么等级？是否必须绑定一个可信业务主体？是否存在人工审批意图？是否涉及敏感审计信息？执行时有哪些基本约束？

现实中的团队通常不是没有处理这些问题，而是把答案分别放在了提示词、平台配置、网关插件、审批代码、日志模块和开发文档里。

这在一个小规模项目中完全可以工作。

但当一个业务系统同时服务多个 Agent、多个入口、多个模型和多个运行时，碎片化的代价就会逐渐显现：同一个退款能力在不同平台中有不同风险描述，同一个审批条件被维护了多份，模型迁移后没人能确认治理配置是否完整迁移，安全人员也无法从接口契约中直接看到 Agent-facing 的能力边界。

问题不是行业完全没有治理，而是治理缺少公共语义。

四、一个问题被准确命名之后，才可能成为公共知识

技术史上，很多重要进步并不是从发明一个庞大系统开始的，而是从准确识别一个反复出现的问题开始。

在问题没有名称时，每个团队都会把它当成自身项目中的特殊情况：

• 有人把它称为“AI 接口安全”；
• 有人把它归入“工具权限”；
• 有人把它写成“Agent 网关规则”；
• 有人把它放进“工作流审批”；
• 有人干脆认为这只是提示词工程的一部分。

这些说法都碰到了真实问题的一部分，却很难让产品经理、开发者、安全团队和架构师围绕同一个对象展开讨论。

当我们把“Agent 进入存量业务系统、代表真实主体产生业务结果”单独识别为一种场景，并把它称为 A2B，Agent-to-Business，变化并不只在于多了一个缩写。

它让一类分散问题有了共同讨论对象：

一旦问题被命名，我们才能进一步讨论它需要哪些基础语义、哪些责任属于运行时、哪些责任必须留在业务系统，以及哪些内容有可能形成跨实现的公共契约。

命名不是为了制造术语，而是为了减少整个行业反复解释同一类问题的成本。

五、公共契约的价值，不是让所有实现变得相同

提到标准或契约，人们很容易联想到一种强制统一：所有人使用同一种产品、同一套平台、同一个执行流程。

但真正有生命力的公共标准，往往不是统一所有内部实现，而是在异构系统之间建立最小共识。

HTTP 没有规定网站必须使用哪一种语言开发；OpenAPI 没有规定服务端必须使用哪一种框架；一种 Agent 能力契约同样不应该规定企业必须使用哪一种模型、审批系统、身份平台或数据库。

它真正需要稳定下来的，是不同参与者之间必须共同理解的那一小部分语义。

这可以借用互联网架构中经典的“薄腰”（thin waist / hourglass）结构来理解：

不同模型、Agent、交互渠道和编排框架↓ 一组稳定、可机器读取的治理语义↓不同网关、运行时、审批系统和业务系统

上层可以快速创新，下层可以保留企业自身复杂性，中间只维持足够小、足够稳定、能够跨实现成立的共同语言。

公共契约的目标不是消灭差异，而是让差异仍然能够协作。

六、最重要的边界：可触达不等于有权限

任何关于 Agent 行动治理的公共思想，都必须守住一条基础边界：

治理契约管理 Reach：Agent 最多可以触达哪些能力。业务系统掌握 Authority：这个主体此刻究竟能不能执行。

这两个问题看起来接近，实际上不能混为一谈。

“退款申请是一个高风险能力，并且调用时必须绑定可信主体”，是一项相对稳定、可以跨运行时理解的声明。

但“当前员工能不能为这个订单退款 5000 元”，依赖的是实时业务事实：员工属于哪个组织，订单归属谁，订单当前是什么状态，可退款余额还剩多少，企业内部风控是否允许。

这些答案只有业务系统能够权威掌握。

无论 Agent 运行时做了多少治理，业务系统都不能放弃最终授权。因为任何中间层都有可能配置错误，也可能被绕过；真正的数据隔离、权限校验和业务规则必须在所有调用路径上成立。

这条分界的社会意义在于，它阻止我们把机器的“理解”误认为组织的“授权”。

模型可以判断用户想做什么，却不能仅凭判断就获得做这件事的权力。

把这条边界放回退款场景

假设员工让 Agent 为订单发起 5000 元退款，一条完整链路可以这样分工：

1. OpenAPI 描述 order_id、amount 等请求参数和响应结构；
2. Agent 能力契约 声明退款能力是否开放、风险等级、是否要求可信主体、何时表达人工审批意图，以及基本审计和执行约束；
3. Agent Runtime 或控制面 绑定实际操作主体，评估声明，必要时暂停并等待外部决定，同时确保批准证据只对应被审阅的那组参数；
4. 企业策略系统 可以继续基于部门、角色和环境做本地决策，但不会因此取代业务校验；
5. 订单系统 最终检查员工权限、订单归属、当前状态、可退款余额和租户隔离，随后决定执行或拒绝，并留下结果证据。

这里没有任何一层单独完成全部治理。公共契约的价值，是让各层在不相互越权的前提下，对同一项 Agent-facing 能力形成稳定分工。

七、薄，并不意味着不完整

第一次看到一份 Agent 能力契约，人们很自然会问：

• 为什么不把具体审批人写进去？
• 为什么不定义完整身份格式？
• 为什么不描述跨接口事务？
• 为什么不规定回滚和补偿？
• 为什么不增加企业审计保存期限？
• 为什么不直接定义所有动态业务规则？

这些问题都重要，但重要不代表都应该进入公共契约。

具体审批人依赖组织结构，身份解析依赖企业的身份系统，事务与补偿依赖工作流和业务语义，日志保存期限依赖企业合规制度，动态权限依赖实时业务数据。

如果把这些内容全部塞进一个所谓通用标准，它很快就会变成一套没有任何企业能够完整实现的万能策略语言。

更危险的是，一些字段可能制造虚假的安全感。

例如，在声明里写下“跨接口操作是原子的”，并不会自动产生分布式事务；在网关层覆盖一个租户参数，也不能取代业务系统的数据隔离；写下一个跨字段表达式，更不能自动解决数据从哪里来、是否可信、何时失效以及获取失败后怎么办。

克制不是回避问题，而是尊重问题真实所属的层次。

一份公共契约真正的完整性，不在于字段足够多，而在于它定义的每一个字段都能够：

• 在不同实现中保持一致含义；
• 不依赖某个产品的私有数据库和 UI；
• 不越过业务系统的最终授权；
• 具有明确的失败语义；
• 可以被机器校验和验证；
• 在版本演进时不因静默忽略而削弱声明者的安全意图。

标准的难度从来不只是增加能力，更在于知道什么不应该进入核心。

八、治理并不是给 Agent 踩刹车

安全治理经常被理解为限制创新：更多规则、更多审批、更多阻力。

但在 Agent 进入真实业务的过程中，情况恰恰相反。

如果一个组织无法解释 Agent 能接触什么、代表谁行动、何时需要人工介入、执行结果如何追踪，它最理性的选择就是不开放高风险能力。

于是大量 Agent 项目会停留在：

• 回答帮助文档；
• 查询公开信息；
• 生成操作建议；
• 创建不产生后果的草稿；
• 展示一个看起来聪明的演示。

而真正有价值的企业工作，往往发生在写操作里：修改状态、处理退款、调整库存、创建工单、维护客户、执行审批、跨系统完成任务。

只有当行动边界能够被可靠治理时，企业才可能放心地逐步开放这些能力。

因此，治理不是 Agent 能力的反方向，而是可信委托能够继续扩大的前提。

九、这套思想降低的是全行业的重复试错成本

如果没有公共参考，每一家准备让 Agent 操作业务系统的企业，都要重新回答风险、主体、审批、审计、业务授权和治理归属等问题。优秀团队能够形成可靠方案，但整个行业仍会重复支付同一笔认知成本；经验不足的团队则可能把安全寄托在提示词或某一个中间层上。

一套公开的治理元模型，即使没有被原样采用，也可以成为参考基线。企业可以直接实现、在内部契约中借鉴，或者公开质疑并提出更好的方案；重要的是，后来者不必从完全空白的问题空间重新开始。

把私人项目中的经验，转化为任何人都能阅读、批评和改进的公共知识，本身就是开源标准最朴素的社会价值。

十、未来的生态不会只有一个入口

未来的 Agent 生态大概率仍然是多元的：企业会同时使用不同模型、Agent 平台、云服务和执行器；治理能力也可能出现在独立控制面、API Gateway、Agent 平台或业务系统内部。

如果治理语义只存在于某个平台内部，更换平台和复用业务能力就会产生大量重复配置。中立契约的价值，不是争夺运行时位置，而是让不同产品可以围绕同一份声明工作：

它可以通过 OpenAPI 扩展被描述；可以通过 MCP 或其他协议被传递；可以由 Agent 平台读取；可以由 API Gateway 执行部分策略；可以由独立控制面落实治理；最终由业务系统完成权威校验。

实现形态可以竞争，基础问题却可以共享。

十一、如何评价一份仍在早期的公共规范

一套新思想刚刚出现时，人们最容易用当前数字衡量它：有多少用户、多少实现、多少下载、多少企业接入。

这些指标当然重要，因为没有实践的标准无法证明自身价值。

但对于仍处在问题定义阶段的公共规范，还要看它是否识别了一个反复出现的问题，建立了共同词汇，划清了责任边界，并提供了可验证、可争论、可继续演化的公共起点。

这些条件只能证明它值得继续验证，不能代替采用数据、独立实现和生产经验。我们不应把“具备长期研究价值”“形成事实标准”和“成为唯一标准”混为一谈；后两者必须由生态协作和真实运行共同证明。

十二、ACC 是这套思想的一次公开范式实践

在这样的背景下，ACC，Agent Capability Contract 的位置才变得清楚。

ACC 不是这篇文章的前提，也不是关于未来的唯一答案。它是对上述问题的一次公开、可机器读取、可验证的范式实践。

它尝试做几件事：

1. 用 A2B 描述 Agent 安全、可治理地进入已有业务系统工作的场景；
2. 把能力边界、风险、主体、审批意图、审计和执行约束提炼为公共语义；
3. 坚持 Reach 与 Authority 分离，让业务系统保留最终权限；
4. 保持核心足够薄，使声明不绑定特定模型、平台、网关或审批产品；
5. 通过 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 如何安全进入真实世界时，是否仍然绕不开它所提出的那些基础问题。

延伸阅读：

• [Agent Capability Contract]
• [NIST：Attribute Based Access Control]
• [OASIS：XACML 3.0]
• [Open Policy Agent：Philosophy]
• [Cedar Policy Language]
• [RFC 3439：Internet hourglass / thin waist architecture]