设想一家企业给运营团队采购了 AI 账号，又接入几种模型服务。
采购清单很清楚：多少个席位，哪些模型，每月多少额度。员工也确实开始使用，有人写文案，有人整理表格，有人尝试让助手查询库存、生成活动图片。
一个月以后，负责人想知道，这笔投入让团队多了什么能力。
答案可能有些分散。文案出得更快了，但发布前仍需反复核对；库存可以在对话里查询，但换个账号就找不到原来的授权；活动图片已经生成，后台却没有明确记录谁可以把它发布出去。遇到失败，仍然需要最熟悉系统的那个人来处理。
这是一个假设场景。它并不说明采购模型或席位没有价值，而是在提醒我们：可使用的 AI 资源，与一家企业能够稳定完成的工作之间，还有一段需要组织起来的过程。
模型能力值得购买。企业同样需要弄清楚，这些能力怎样进入自己的工作，形成可以安排、核对、调整和持续维护的服务。
从“提供什么能力”走到“允许完成什么工作”
更好的模型，可以帮助人理解材料、比较方案、发现遗漏；一个设计得好的客户端，可以减少重复输入，让员工更容易把 AI 用起来。这些收益本身就成立，不必每次都以自动操作业务系统来证明价值。
对一个主要写作、阅读和分析的小团队，合适的账号，加上清楚的数据使用约定，可能已经解决了相当一部分问题。
当委托进一步走向“帮我完成一段工作”，采购的判断尺度就需要变化。
“能处理长文本”描述的是模型的一项能力。“每周根据指定仓库的可售库存，生成可核对的补货建议，并由采购人员决定是否下单”，则描述了一项组织可以安排的工作。后者还包含数据口径、任务频率、接收人、完成标准和决策权限。
模型越能处理开放目标，这些条件就越值得说清楚。否则，模型可能很认真地完成了一个与企业预期不同的任务，而双方都觉得自己没有做错。
这里的“可管理”，也不等于把每一步都固定下来。企业可以给分析和创作留下空间，同时明确哪些数据可以使用，哪些动作需要确认，什么结果能够交付。管理的对象是委托的边界与后果，不必是模型每一次探索。
一项工作，可以组合多种模型与工具
再看一场假设的商城促销。
运营人员希望助手核对库存，整理活动方案，生成几张候选海报，最后把审批通过的内容写入后台。这里既有文字分析，也有图片生成，还有来自业务系统的数据查询与修改。
它们可以由不同的服务完成。对话模型适合组织任务，图片模型负责生成素材，库存接口提供当前事实，商城接口执行获准的变更。具体怎样组合，需要根据质量、响应时间、数据要求和成本验证，不能只靠模型数量判断方案是否先进。
多模型带来的选择权，也带来新的协调责任。谁决定切换，哪些内容会发给新的服务，能力不可用时怎样解释，原请求能否继续核对，都需要在运行系统中落实。
Google 的 Gemini 自定义函数调用文档就区分了两个环节：模型生成函数名称和参数，应用执行相应代码，再把结果交回模型。这说明结构化的调用请求仍要经过实际执行过程，不能把模型输出当成业务已经完成的证明。
同样，海报生成成功，只能说明拿到了图片。能否作为活动素材使用，是否经过品牌审核，谁有权发布到商城，仍属于后面的工作条件。
我的判断是，企业采购时应该把这些组合关系看清楚。可以选择一体化产品，也可以自行组合服务，但都需要知道：每一部分承诺什么，哪里需要企业继续接手。
AI 预算与业务预算，是两份不同的账
如果所有调用都来自一个入口，给团队分配一份统一额度，确实可以简化使用。员工不必为每一种模型分别找管理员，管理者也比较容易理解资源消耗。
但是，这份额度表达的是资源安排，不能自动表达业务授权。
给运营人员增加图片生成额度，不意味着允许他发布任意广告；同意助手多做几轮分析，也不意味着允许它扩大折扣范围。模型调用消耗的是 AI 资源，促销让利、退款和采购订单影响的是企业经营，两者即使都能用金额表示，也需要不同的决策依据。
混在一起，可能出现一种危险的错觉：账户还有余额，所以动作可以继续。实际上，一次几乎不产生模型费用的业务调用，也可能修改大批商品价格。
另一种混淆发生在成本解释上。套餐售价、可使用额度、计量时采用的参考价格，以及供应商最终收取的费用，未必是同一个数。统一计量可以方便管理，但不能让这些含义自动变得相同。使用参考价格时，应当说明对应关系，而不是把参考报价直接称为实际成本。
企业还需要知道，预算究竟控制什么。它可以约束允许消耗的资源，却不能独自证明工作值得做；一项任务没有超预算，也可能产出大量无人采用的内容。
因此，资源账应该与工作记录关联，让负责人看得见钱花在了哪类任务上。关联并不要求把所有业务权限都塞进计费系统。支付、合同、汇率和退款仍由相应业务流程处理；一次额度调整，也不应悄悄改写原来的操作权限。
把职责分开，才知道出了问题找谁
企业不一定要亲自维护每一层技术，但需要有人对各层的运行负责。
模型服务提供生成与推理能力；客户端组织上下文和交互；运行环境决定怎样串联步骤、保存进度和处理取消；业务系统提供数据与动作，并检查当前用户的权限和业务条件。管理者则需要决定目标、资源和验收标准。
这些角色可以由同一家供应商承担，也可以分布在不同团队。采购方式不会让其中某项职责自然消失。
MCP 的官方架构把宿主、客户端和服务器分开：宿主承担协调、安全策略与同意要求等职责，服务器提供工具或资源，并遵守安全约束。这是一种工程上的职责划分，不代表接入了协议就自动完成了企业治理。
对于企业，更有用的追问是：模型选错工具时谁来改进？员工权限被撤销后，谁保证下一次调用不能继续？请求超时了，谁能确认究竟有没有执行？业务规则变更之后，谁负责更新说明和验收场景？
请求超时不代表动作没有发生；重试前要能够确认原操作的状态，避免把一次委托执行两次。
如果这些问题只能由几个系统互相转述，就很难形成稳定服务。
可追溯的记录能帮助排查，但记录本身也不等于责任已经落实。组织还需要明确谁有处理权、如何升级问题，以及什么情况下停止新增动作，交给人接手。
客户端可以变化，工作条件要有稳定依据
不同员工可能偏好不同入口：运营在桌面助手里准备方案，负责人在业务系统里审批，固定报表通过工作流生成。这种差异可以是正常分工，不必强求所有人采用同一种界面。
要支持这种选择，企业需要维护一些能被多种入口使用的依据：准确的数据含义、可信身份、业务权限、动作约束和结果记录。
例如，库存里的“可售数量”不应随着客户端切换而换一种解释；价格审批也不应因为换了模型，就失去原来批准的商品范围。
但可复用不等于可以搬运所有东西。新客户端需要自己的授权与适配，旧会话里的批准不能因为文字被复制过去，就自动变成新入口的操作许可。新模型是否仍能正确理解工具、遵守数据约束，也需要验证。
这部分投入的价值，是降低每次变更时重新建立信任的成本。企业可以试用更合适的模型或交互方式，同时利用已有业务定义与验收材料判断它是否胜任。
从这个角度看，可管理的工作能力还包含一种调整能力：某个供应商、模型或入口变化时，企业知道影响在哪里，也有办法逐步替换，而不是被迫在“全部重做”和“继续将就”之间选择。
投入产出，应该落到具体任务上
使用率、调用量和生成数量，可以说明系统有多活跃，却不足以说明业务变好了多少。
一次库存核对，节省了多少整理和复查时间？一份营销草稿，经过多少修改才能采用？一次后台操作，出现异常后需要谁花多长时间处理？这些问题更接近企业真正承担的成本。
评估时还应把数据整理、接口适配、维护和培训算进去。某个方案的单次模型调用很便宜，可能需要更多人工补救；另一个方案调用费用更高，也可能减少反复确认。哪种更合算，需要在相近任务和相同质量要求下比较。
也不必把所有工作强行折算成一个“成功次数”。一张图片是否合适，可能需要主观判断；一项经营建议是否有效，还会受到执行、市场和时间的影响。容易计数的结果，不一定就是企业最关心的结果。
按结果收费可以是一种商业安排，但计价单位不能代替验收标准。双方仍要说明什么叫完成、结果如何核对、哪些条件由谁提供、争议怎样处理。账单写成“成功处理一次”，不会自动解决这些问题。
更有解释力的做法，是先记录一类任务原本怎样完成，再比较引入 AI 后，质量、周期、人工投入和异常处理发生了什么变化。起初未必能算出精确收益，但至少能够区分：哪些改善有证据，哪些只是演示里的观感。
从一段值得委托的工作开始
这种建设不必从统一平台开始。
企业可以先选择一项频率适中、范围明确、结果容易核对的任务。把任务交给谁、能够使用哪些数据、做到哪一步需要人决定、失败后怎样接手，先约定清楚，再观察实际运行。
简单的单次模型调用如果已经够用，就没有必要为了展示自主性而增加循环。Anthropic 在《Building effective agents》中也建议从简单方案开始，根据评估需要增加复杂度；文中对工作流与 Agent 的区分，可以作为设计参考，不能据此推导所有企业都应该采用复杂 Agent。
随着使用深入，再决定哪些能力值得集中管理。也许先需要统一模型额度，也许最急迫的是业务身份接入，或者只是把原本模糊的“操作成功”变成可查询的结果。
推进顺序应由真实问题决定。增加一层系统，就多了一份维护责任；只有减少的重复工作、协调成本或风险足以支撑它，这层系统才值得长期存在。
让采购留下可以继续积累的东西
我们关注的 Agent-to-Business，讨论的就是 Agent 如何进入既有业务系统完成工作。模型、入口与治理之间的分工，是这个方向需要持续验证的一部分。
ACC，即 Agent Capability Contract，是独立、实现中立的能力声明协议，用于表达业务动作的开放与治理要求。它不承包企业的工作流程，也不取代业务系统的最终授权。
百灵中枢 BailingHub 是这一方向的开源工程实践，连接业务能力、可信身份、审批与执行记录，并提供可选的模型计费网关。在本地 Agent 的接入方式下，任务编排由该 Agent 的运行环境承担，计费网关不接管编排或业务授权。协议、产品和企业自己的管理制度，需要各自承担对应的职责。
企业可以买模型、买席位、买行业应用，也可以采购集成与运维服务。值得追求的是，这些投入逐步留下清楚的工作定义、可验证的结果和能够继续维护的运行经验。
当同事能够接手、管理者能够判断、系统变化后仍有依据可以调整，AI 的能力才更扎实地成为了企业的工作能力。
拓展阅读
- ACC：独立开源规范与设计说明。声明语义、实现责任与最终业务授权分别说明。
