一份面向 Agent 的能力契约应该描述到什么程度当开发者第一次看到 ACCAgent Capability ContractAgent 能力契约里的enabled、scope、risk、subject、approval和execution很容易继续追问既然已经有approval为什么不直接声明谁能审批、要几级会签既然已经有subject为什么不把tenant_id、角色和数据权限一起标准化既然已经有条件审批为什么不支持累计金额、跨工具前置条件和事务回滚既然要让 Agent 安全办事为什么不把整套企业策略都写进同一份契约这些问题都很合理。但答案不是“ACC 还没来得及加字段”而是其中很多能力有意没有进入 ACC Core。一个开放契约的目标不是用一份越来越大的 YAML 接管企业已有的身份系统、审批平台、租户模型和工作流引擎。它应该只标准化那些能够被不同运行时一致理解、确定执行并通过 Conformance 验证的最小治理语义。这篇文章只讨论一个核心问题为什么审批人、租户隔离、业务规则和事务编排明明都很重要却不应该被塞进 ACC 核心我们也会结合 BailingHub 的实现说明标准没有定义某项能力不等于产品不能实现产品实现了某项能力也不等于它自动成为开放标准的一部分。一、先看一份“什么都想管”的巨型注解假设我们准备给退款接口增加 Agent 能力声明并试图一次性把所有规则写进去# 下面是刻意设计的反例并不是 ACC 字段x-agent-capability:enabled:truescope:refund.executeapproval:approver_role:finance_managerlevels:2delegates_allowed:truetimeout:24hescalation_to:finance_directortenant:source:jwt.claims.tenant_idisolation:row_leveltable_field:merchant_idpolicy:expression:amount order.refundable_amountdata_source:mysql.orderstransaction:steps:-freeze_balance-create_refund-update_order-notify_customercompensate:create_refund:cancel_refundfreeze_balance:unfreeze_balance它看起来很完整甚至很“企业级”。但换一个组织问题马上出现审批人可能不来自role而来自部门、金额区间、项目归属、临时授权或 OA 流程有的系统使用 JWT有的使用 PHP Session、企微成员 ID、证书、服务账号或签名票据有的租户按数据库隔离有的按 Schema、行级字段、组织树、商户关系或资源归属隔离refundable_amount是实时业务状态不是能力契约中的常量退款的补偿不一定等于调用一个反向接口还可能涉及资金渠道、对账、人工介入和不可逆外部通知无 UI 的网关、队列消费者和命令行 Agent根本没有同一种审批交互界面。于是这份看似统一的声明实际上只是把某个产品、某个组织和某套数据库的假设写成了公共字段。其他实现即使能解析 YAML也无法以相同语义兑现它。这不是可移植标准而是把私有业务系统藏进注解里。二、一个字段进入 ACC Core必须先通过六道门ACC 的设计依据给出了一组核心字段准入测试。一个新字段至少需要同时满足它会改变可移植的 Agent 治理语义相互独立的 Parser 或 Runtime 能实现相同含义不依赖某个产品的私有数据库、UI、身份目录或工作流就能测试行为目标 Binding 的原生 Schema 和标准机制尚不能清晰表达它它不要求 Agent Runtime 成为最终业务授权方旧运行时忽略它时不会静默降低安全性否则必须进入新的 Major 兼容边界。即使全部通过也只代表这个字段有资格进入治理评审还要继续回答是否在多个独立实现中出现了同一种需求默认值、优先级和失败语义是否完整是否具备机器可读测试向量是否存在更合适的 Binding、扩展或相邻协议加入核心后生态实现成本是否值得。这组测试背后有一个朴素原则字段不是越多越安全。无法被不同实现一致执行的字段只会制造“已经治理”的错觉。三、为什么 ACC 声明“需要审批”却不声明“谁来审批”ACC 可以声明一项调用需要形成审批意图approval:required:true也可以针对本次调用参数声明条件审批approval:when:-param:amountop:value:1000label:退款金额超过 1000 元这两种语义都具有可移植性。任何合规 Runtime 都可以观察到一次具体调用的amount按严格 JSON 类型比较并确定本次调用是否应该先产生审批意图但下面的问题没有统一答案谁有资格批准 在哪里批准 需要几个人 是否允许委托 审批多久过期 主管休假时如何升级 法务和财务是串行还是并行 批准记录由谁签名并长期保存这些答案依赖组织结构、权限目录、业务类型、审批系统、合规要求和实时状态。如果 ACC 增加一个看似方便的字段approval:approver:finance_manager它会立即引入一串无法由 Core 回答的问题finance_manager是角色名、用户组、岗位编码还是外部目录 Claim谁证明当前审批人属于这个角色角色刚刚被撤销怎么办跨公司、跨租户时这个角色属于哪个组织代理审批、会签和条件升级怎样表达一个无 UI Runtime 应该把审批送到哪里因此ACC 只声明审批意图不定义审批流程所有权。BailingHub 怎样承接这条边界BailingHub 会在高风险或条件命中的调用上冻结具体调用快照形成ApprovalIntent其中包含job_id request_id subject tool scope risk args args_hash审批可以被投递到业务侧 Webhook、IM/OA 卡片或由中枢控制台在轻量场景中兜底。业务侧返回ApprovalDecision时中枢会复核任务身份和args_hash只放行与批准快照完全一致的那次调用。但 BailingHub 仍不维护企业的组织关系、审批人权限和多级审批规则。生产环境中谁能审、在哪里审、是否会签、审批证据如何归档仍由业务审批所有者决定。这说明ACC声明需要审批 BailingHub冻结调用、投递意图、验证决策、精确放行 业务审批系统决定谁能批准以及流程如何完成三层缺一不可但不能互相冒充。四、为什么subject.required不等于标准化租户隔离ACC 可以声明这项能力必须存在可信行动主体。subject:required:true它的可观察结果很明确当 Runtime 没有可信主体时该工具不应该暴露给 Agent也不应该在调用层被放行。但 ACC 不规定主体必须长什么样。真实系统可能使用tenant_1:user_1001这样的结构化主体JWT 中经过验证的租户和用户 Claim后台 Session 对应的员工 ID企微、飞书或钉钉成员标识mTLS 证书绑定的服务主体业务系统签发的短期票据服务账号加单独的委托证明。这些机制的发行者、有效期、信任域和撤销方式完全不同不能因为都包含一个字符串就被视为同一种身份保证。租户隔离为什么必须留在业务系统假设工具入参中有{tenant_id:tenant_2,order_id:SO-1001}如果tenant_id来自模型输出用户只要要求模型换一个值就可能尝试访问其他租户。即使tenant_id由网关注入也仍然不能代替业务系统自己的对象级检查。因为攻击者或内部服务可能绕开 Agent Runtime直接访问原 API。真正的租户隔离应该满足无论请求来自人类后台、Agent Runtime、内部任务还是直接 API 调用 - 业务系统都从可信身份上下文恢复租户 - 查询和写入都限定在授权数据边界内 - 目标对象不属于该租户时 fail closedACC 的subject.required可以阻止匿名 Agent 获得这项工具scope可以限制某条 Agent 路由最多触达哪些能力但它们都不是最终租户权限。BailingHub 的实现方式BailingHub 把可信业务主体作为不透明值传给业务工具并将其钉入请求签名。接入方可以使用tenant_1:user_1001之类的结构化主体也可以映射成自己的身份形式。中枢不解释这个主体究竟对应哪张用户表、哪个商户层级或哪种行级策略。业务 API 验证调用来源后仍要解析可信主体恢复真实租户上下文查询原业务权限核对目标订单、员工或资源归属在不满足条件时拒绝。这不是 BailingHub “少做了一层”而是避免把每个 SaaS 完全不同的租户模型硬编码进通用中枢。五、为什么单次条件审批不能变成通用策略引擎ACCapproval.when有意只处理有限、类型安全的单次调用条件。例如approval:when:-param:amountop:value:1000Runtime 可以确定性地判断当前 JSON 参数是否命中。但它不表达累计、滚动窗口、跨调用或序列约束。例如下面三次调用都没有单次超过 1000 元第 1 次退款400 元 第 2 次退款400 元 第 3 次退款400 元如果业务规则是“同一订单当日累计退款超过 1000 元必须财务复核”只看每次调用的amount就会漏掉累计 1200 元的事实。要正确计算它系统必须知道哪些历史调用已经成功哪些仍在审批或结果不确定统计窗口使用哪个时区退款撤销后是否释放额度多实例并发时如何原子更新当前业务数据是否仍然新鲜。这些已经不是一个参数条件而是一套有状态策略系统。同理下面的规则也不适合直接塞进 ACC Core退款金额 当前订单可退余额 员工只能导出自己管理部门的数据 过去 24 小时累计发券不超过 5000 张 先完成库存预占才能创建订单 合同金额变更后必须重新执行法务检查它们依赖权威业务数据、读取权限、时效、并发和失败处理。ACC 如果只提供一个通用expression字符串却不定义数据来源和一致性就会制造半成品策略语言。一个真正的通用策略引擎需要类型系统表达式语法权威数据源数据读取授权时效和缓存规则确定性失败语义执行沙箱冲突与优先级规则可解释和可审计的决策结果。这已经是 OPA、Cedar 或企业策略服务所在的责任层而不是一个能力声明字段应该假装解决的问题。六、为什么工具顺序、事务和补偿不属于能力声明考虑一条“创建订单”的业务流程校验客户状态 - 锁定库存 - 创建订单 - 扣减余额 - 发送通知如果第三步成功、第四步超时系统应该怎样处理回滚订单还是等待余额结果确认库存锁定是否可逆通知已经发送还能撤回吗重试会不会重复扣款补偿动作本身需要什么权限和审批外部支付渠道返回不确定结果时是否应该自动重试这不是五个工具描述的简单相加而是一个 Saga、事务或工作流问题。ACC 声明的是单项业务能力面向 Agent 的治理边界。它可以告诉 Runtime某个工具是否启用属于哪个scope自动发起的最坏后果等级是否需要可信主体本次参数是否命中审批是否只读、幂等、需要超时或限流。但“工具 A 成功后才能调用工具 B”“工具 B 失败后必须补偿工具 A”属于跨操作的状态机。把这类顺序塞进能力声明会让一个描述“能力是什么”的契约变成描述“业务流程怎么跑”的工作流语言。不同组织的重试、补偿、人工介入和一致性要求不可能靠几个通用字段自动统一。BailingHub、n8n 和业务工作流怎样分工BailingHub 可以承载持久任务、审批暂停、结果续查、工具调用幂等和 Trace也可以由 Agent 在一个任务中选择多个工具。n8n、LangGraph、业务流程引擎或自研服务则可以负责确定性的步骤编排。但无论由谁编排真正的业务事务语义仍需要业务所有者明确设计哪些步骤可以重试 哪些结果属于不确定 哪些动作需要补偿 补偿是否还要授权 什么时候必须转人工 最终状态由哪个系统记录产品可以提供这些能力ACC Core 不需要因此变成另一个工作流引擎。七、“不进入 Core”不等于“无法表达”业务私有信息仍然可以放在正确的位置。1. 优先复用 Binding 原生机制业务参数继续使用 OpenAPI Schema响应结构使用标准responses认证方案使用协议已有机制。ACC 不复制一套请求和响应 Schema。2. 使用带命名空间的扩展OpenAPI Operation 可以保留业务扩展x-business-owner:trade-teamx-business-policy:approval_scene:order_over_limitworkflow_key:refund_v3ACC 兼容 Runtime 可以把它们放进扩展袋交给明确支持这些字段的产品或二开模块消费。关键边界是未经标准化的扩展不能静默改变scope、风险、审批、限流、审计或签名等安全行为。否则同一份声明在支持和不支持该扩展的 Runtime 中可能得到相反安全结果。3. 把权威规则放回业务 API例如退款金额不得超过当前可退余额应由退款预检或执行 API 使用最新订单状态判断。即使调用绕过 Agent Runtime这条规则也必须成立。4. 把组织流程交给审批和工作流所有者接口只声明“这项动作需要审批”部署配置决定审批意图发往哪里业务审批系统决定谁能审以及流程怎样完成。这样既保留开放契约的可移植性也不会阻止企业使用复杂流程。八、ACC、BailingHub 和业务系统的完整责任图可以把整条链路画成OpenAPI / MCP / 其他 Binding 负责接口事实与原生 Schema | v ACC 声明 enabled / scope / risk / subject / approval / audit / execution / guidance 负责可移植的 Agent 触达与治理意图 | v BailingHub 等 Agent Runtime 工具装配、路由白名单、可信主体闸、审批意图、参数快照、限流、幂等、审计、Trace | ------ 企业身份与委托系统 ------ OA / IM / 审批平台 ------ n8n / Saga / 业务工作流 | v 业务系统 Authority 租户隔离、对象权限、实时状态、业务不变量、最终写入与结果其中ACC 负责让不同 Runtime 对最小治理语义形成共同理解BailingHub 负责消费声明并执行具体控制面机制企业现有身份、审批和工作流系统继续承担各自权威责任业务系统在调用时做最终授权。“薄标准”并不是缺少这些组件而是拒绝对不属于自己的组件作虚假保证。九、一条真实接入应该怎样落地第一步先把业务动作拆成原子能力不要把“完成整套退款流程”暴露成一个含糊工具。优先拆成refund.preview refund.request.create refund.status.get refund.execute查询、预检、创建申请和真实执行具有不同后果也应有不同风险与审批策略。第二步用 ACC 声明可移植治理意图x-agent-capability:version:1enabled:truescope:refund.request.createrisk:level:mediumsubject:required:trueapproval:when:-param:amountop:value:1000audit:sensitive:trueexecution:readonly:falseidempotent:false这份声明让 Runtime 知道 Agent 是否可触达、是否需要主体、何时先形成审批意图以及调用应怎样被审计和约束。第三步由业务侧建立可信主体用户登录、租户归属和身份票据应来自可信业务代码不经过模型生成。Runtime 只接受经过验证的主体上下文。第四步接入真实审批所有者生产环境优先让审批意图进入现有 OA、IM 或业务审批页。审批回调需要绑定任务、工具和精确参数快照不能只返回一个裸approvedtrue。第五步业务 API 继续执行最终授权验签成功只证明请求来自可信中枢不证明该主体有权操作目标对象。业务系统仍要校验租户、角色、资源归属、订单状态和业务不变量。第六步多步骤流程交给确定性编排需要顺序、等待、重试、补偿或人工介入时使用业务工作流、Saga、n8n 或其他显式状态机。不要把跨步骤事务寄托在模型临场规划上。第七步用负向测试验收边界至少验证无可信主体时受保护工具不可见且调用被拒错误args_hash的审批决策无法放行审批人权限被撤销后审批系统拒绝决策伪造其他租户资源时业务 API fail closed多次小额调用命中业务累计上限时仍被拦截工作流中途失败时按已定义状态进入重试、补偿或人工对账绕过 Agent Runtime 直接调用业务 API 时租户和业务规则仍然成立。十、怎样判断一个新字段应不应该进入 Core以后再遇到“能不能给 ACC 加一个字段”的问题可以先用下面的清单过滤。可移植性两个没有共享私有代码的 Runtime能否给出相同解释字段是否依赖某个组织的角色名、数据库或 UI可测试性能否用有限输入和预期输出形成机器可读测试向量失败时应该拒绝、降级还是产生更多审批是否足够明确层级归属Binding 的原生字段是否已经能表达它是否实际上属于身份、授权、审批证据、策略或工作流协议是否要求 Runtime 读取业务私有数据并成为最终授权方安全兼容旧 Runtime 忽略它时会不会更宽松如果会是否需要新的 Major 家族或能力协商而不是悄悄增加一个可选字段实现证据是否已经在多个独立实现中出现同一问题是否先通过带命名空间的扩展完成过真实验证如果这些问题还没有答案先作为实现扩展存在通常比急着进入 Core 更安全。十一、标准与产品必须允许不同速度演进ACC 是实现中立的能力契约。BailingHub 是消费 ACC 的一个开源实现。它可以提供审批意图账本和回调主体传递与签名持久任务和有界等待幂等、限流、审计和 Trace控制台、渠道适配与运行状态。这些产品能力可以比标准更快演进也可以保留部署特有的选择。但不能反过来说因为 BailingHub 实现了一个功能所以 ACC Core 必须增加同名字段。真正进入标准的语义需要证明它能够跨实现成立并具备明确的 Conformance 行为。同样其他 Runtime 可以用完全不同的数据库、审批系统和身份桥实现 ACC只要它对规范字段给出一致的可观察结果。标准与产品分离带来的不是割裂而是两个重要自由标准可以保持中立、稳定和可移植 产品可以针对真实部署快速完善运行能力十二、写在最后边界清楚才是真正的完整企业 Agent 当然需要审批人、租户隔离、业务策略和事务编排。但“需要”不等于“都应该由一个契约定义”。一份可靠的能力契约应该准确声明自己能够兑现的最小语义并明确把其他责任交还给真正拥有权威数据和组织流程的系统。所以 ACC 的完整性不体现在字段覆盖了多少企业名词而体现在责任链有没有断裂ACC 声明 Agent 触达与治理意图 - Runtime 确定性执行暴露、主体、审批和审计闸门 - 身份、审批与工作流系统完成自己的权威职责 - 业务系统在最新状态下做最终授权如果把审批人、租户模型和事务编排全部塞进 Core契约可能更厚却会更依赖单一产品、更难一致实现也更容易对外作出无法兑现的安全承诺。真正成熟的标准不是看到所有问题都增加字段。而是知道哪些问题必须标准化哪些问题必须留在标准之外并让两边通过清晰接口协作。项目、规范与真实 API 评估入口ACCv1.0.5规范https://github.com/agent-capability/agent-capability-contract/blob/v1.0.5/SPEC.mdACC 中文设计依据与边界https://github.com/agent-capability/agent-capability-contract/blob/v1.0.5/DESIGN_RATIONALE.zh-CN.mdACC 治理与演进规则https://github.com/agent-capability/agent-capability-contract/blob/v1.0.5/GOVERNANCE.mdACC 官网https://agentcapability.org/BailingHubv0.3.4https://github.com/bailinghub/bailinghub/releases/tag/v0.3.4BailingHub 工具模型https://github.com/bailinghub/bailinghub/blob/v0.3.4/docs/TOOLS_MODEL.mdBailingHub 架构说明https://github.com/bailinghub/bailinghub/blob/v0.3.4/docs/ARCHITECTURE.mdBailingHub 开源仓库https://github.com/bailinghub/bailinghub真实 API 接入评估https://github.com/bailinghub/bailinghub/issues/new?templateintegration_evaluation.yml如果你正在评估现有商城、CRM、ERP、OA 或内部管理系统可以只准备“一条脱敏业务 API 当前身份与租户方式 审批由谁承接 一个允许的测试对象”先验证第一条受治理动作不需要公开生产凭据或整套后台。提交公开 Issue 时请勿附带 Token、模型密钥、个人信息或生产业务数据。