“帮我给商城做一场周年庆。”
同一句话，可以对应两种深度完全不同的委托。
一种是让 AI 写一份活动方案。人读完以后，决定采用哪些建议，再到后台逐项配置。
另一种是让 AI 继续做下去：选择商品，准备内容，设置活动，核对库存，把经过批准的方案真正变成一场可以运行的促销。
从前一种走向后一种，变化远远超过少点几次鼠标。企业开始把一部分行动选择交给机器：先做什么、调用哪个系统、遇到问题如何调整，都可能由智能体在执行中决定。
这时，一个问题会逐渐浮现：我们愿意让它做到哪一步？
愿意让它生成商品文案，未必愿意让它直接发布；愿意让它查询库存，未必愿意让它调整库存；即使愿意让它修改价格，也需要明确哪些商品、什么幅度、由谁决定。
这些差别，构成了智能体进入真实业务时必须跨过的一道门槛。
智能能力决定 Agent 能做什么，治理能力决定组织愿意把多少真实业务交给它。
2026年9月14日，全国网络安全标准化技术委员会发布《人工智能安全治理框架3.0》。这份文件延续了风险分类、技术应对与综合治理的逻辑，并结合人工智能发展的新变化更新相关内容。官方发布公告
其中值得智能体开发者认真思考的，是正文对智能体风险与应对的展开，以及附件2《智能体风险管理框架》。它将关注范围延伸到智能体从设计、部署、运行到停用的完整生命周期，涉及身份权限、人工控制、工具管理和监测审计等环节。框架全文，附件2
读到这里，我们更关心的是一个产业问题：当智能体越来越有能力参与真实工作，社会和组织需要怎样的基础条件，才能持续扩大对它的委托？
本文沿着框架中的智能体治理这条主线，讨论我们的理解。
人工智能应用的影响，会随着它进入业务的深度而改变。
一份生成的活动方案，可以由人阅读、修改、放弃。一次实际生效的促销，则会影响消费者看到的价格、商家承担的成本和后续履约。工作仍然由机器完成了一部分，后果却会进入现实中的组织关系。
这意味着，模型对任务的理解能力，需要与组织赋予它的行动资格衔接起来。它可以知道如何调整价格，却仍然需要有权调整；可以判断某项操作有利于目标，却仍然需要尊重组织已经设定的边界。
企业在这里面对的，是一个熟悉问题的新形态：怎样把事情交出去，同时保留必要的决定权。
组织长期通过岗位、权限、流程和记录来协调人的行动。引入智能体以后，这些安排仍然重要，只是需要进一步回答：当执行者能够自行规划步骤、连续使用工具时，原来的规则怎样在整个过程中持续有效？
因此，把 Agent 接到业务接口，只完成了委托所需的一部分条件。另一部分条件，是让组织的规则能够随着任务一起进入执行过程。
行动可以交给智能体，决定委托边界的权力仍然属于人和组织。
这也解释了安全治理与产业发展之间更深的关系。
设想一家企业正在评估，是否允许 AI 帮它维护商品。如果管理者必须逐项盯着每个动作，使用智能体节省的时间就可能被监督成本抵消。如果只能给出一个宽泛的后台账号，又无法解释它实际会触及哪些业务，管理者很可能只开放少量查询能力。
两种情况下，模型的潜力都很难充分转化为业务价值。
治理建设提供了另一条可行路径：组织可以清楚地划定委托范围，把常规工作交给智能体，在影响扩大或情况变化时保留介入机会，并有依据地核对结果。
例如，企业可以先开放商品内容的准备和内部检查，积累使用证据后，再允许它在指定范围内完成发布。价格调整仍然遵循自己的审批制度；库存系统也继续依据实时业务情况作出判断。
这样，放权就有了层次，也有了逐步扩大的依据。
有价值的治理机制还必须经得起使用成本的检验。风险很低、范围明确的工作，如果仍要求反复确认，使用者最终可能绕开控制，或者放弃自动化。真正需要人作决定的时刻，则应当把影响和选择呈现清楚。
由此看，治理水平的提高，可以同时服务于控制风险和提高协作效率。它让企业更容易辨认哪些工作可以交出去，哪些决定应该保留，以及什么条件下可以扩大自主执行的空间。
我们从框架3.0得到的一个重要启发就在这里：可信、可控的运行条件，本身就在创造智能体的应用空间。
这是一项需要通过实践检验的产业判断。治理不会消除模型和业务系统的所有错误，但能够帮助组织限制影响、识别异常并处理后果。当这些条件更清楚，开放真实业务能力的决定才更有依据。
再向前看一步，问题就会从单个智能体的使用，走向整个产业的协作方式。
一家企业可能尝试不同模型，在多个客户端里使用 AI，也可能同时拥有商城、库存、财务和办公系统。执行任务的技术组合会变化，企业自身的业务规则却需要保持连续。
今天允许某个助手在指定商城发布商品，明天换了一个助手，原有的授权边界不应因此失去含义。接入新的库存系统以后，各系统之间如何分工、谁保留最终决定权，也需要重新建立清楚的关系。
如果每一种组合都要单独描述能力、重新解释风险、重新实现审批衔接和执行记录，那么接入对象越多，重复协调的成本就越高。
更麻烦的是，这些实现可能各自使用相似的词，却表达不同的事情。一个系统所说的“允许执行”，可能只是工具可以被看见；另一个系统却把它理解成业务已经批准。单独看每个组件都能工作，连接起来以后，责任之间却可能出现空白。
于是，产业需要面对一个长期问题：怎样让业务能力与治理要求，在不同模型、系统和运行环境之间保持可以理解、可以核对的含义？
模型可以更换，企业积累的能力边界和责任关系应当能够延续。
这就是公共治理契约值得探索的地方。
共同的契约，可以让业务系统用一致的方式表达某项能力的风险、主体要求和审批意图，让不同实现知道应当如何理解这些信息。具体由谁批准、业务状态是否允许执行，仍由相应的组织制度和业务系统决定。
如果这样的表达可以跨实现复用，开发者就有机会把精力放到自己的业务价值上，减少反复约定基础含义的工作。企业也更容易检查不同接入方案之间的差异，保留选择技术供应方和运行环境的空间。
这里所说的基础设施，包括能够运行的软件，也包括大家可以共同讨论和检验的规则。一项能力如何被描述，一次委托怎样受到约束，一条执行记录能够证明什么，都属于这项建设的一部分。
这种共同基础需要足够明确，才能支持互通；也需要保留合理边界，允许不同组织采用自己的制度，允许不同开发者提供不同实现。
这正是我们持续建设 ACC 和百灵中枢的出发点。
ACC，全称 Agent Capability Contract，是实现中立的能力治理契约。它尝试为业务系统面向智能体开放能力时的治理要求，提供可移植的声明方式。能力的风险、所需主体、审批意图和审计要求，可以由不同运行时解释，而无须依赖某个指定产品。
百灵中枢 BailingHub 则是开源业务动作治理控制面。它探索如何把能力发现、授权上下文、执行控制和记录关联到实际运行链路，让治理要求能够进入智能体操作已有业务系统的过程。业务系统始终保留最终授权和拒绝权。
两个项目分别面对契约与执行层的问题，独立演进。ACC 的语义需要能够由其他实现采用，百灵中枢的工程价值则需要在真实接入中验证。
我们与框架3.0的契合，体现在对同一类问题的持续关注：当智能体具有行动能力，身份、权限、人工决定和执行证据怎样保持清楚、连续，并落实到运行过程中。这是项目选择的建设方向，实际成效仍需要具体实现和使用证据来说明。
采用开源方式，也与这一目标有关。
业务系统的维护者需要知道，自己的规则经过中间层以后是否仍然成立；部署者需要看清控制在哪里执行；使用者需要能够理解，一次行动为何被允许、被暂停，或者被拒绝。开放的规范和实现，为检查这些问题提供了条件。
进一步说，如果一种治理要求只能由唯一产品解释，组织更换技术组合时就可能重新面对原来的问题。实现中立的契约与可检查的代码，有助于让治理能力成为能够持续积累的共同基础。
这种价值需要通过不同开发者的实现、复现和反馈逐步建立。开源提供参与和验证的条件，可信程度则来自长期的维护与实践。
对我们而言，值得追求的进展，是让一个普通业务系统能够更清楚地开放能力，让一个智能体能够在明确委托下完成工作，让一个组织能够看懂结果，并据此决定下一次是否愿意交给它更多事情。
回到开头那场商城周年庆。
当经营者能够说清哪些商品可以参与、哪些决定由自己保留，智能体能够在约定范围内持续推进，各业务系统能够守住原有规则，结果能够被核对，这次委托才真正具备了进入日常经营的条件。
而当这种方式可以从一家商城延伸到更多系统，从一个助手延伸到不同执行环境，同时保持边界和责任连续，治理能力就开始产生基础设施的价值。
智能体走向产业深处，需要越来越强的智能，也需要越来越成熟的委托制度。
让组织有依据地放权，是释放智能价值的一部分。
