V2 架构：任务、能力契约与 MCP 资源边界
AI 员工不只是自动回复客户。它需要在正确的业务范围内理解问题、查询实时信息、执行可授权的动作，并把每次结果留在可追溯的运行记录中。
V2 不再把这些事情笼统地归为“Skill、Tool 与 MCP”。它把三个边界拆清楚：
- 任务包：定义一个可复用的业务能力单元，以及它如何完成。
- 能力契约：定义一次查询或操作能做什么、何时可做、输入输出和安全边界。
- MCP 资源绑定：把经过许可的能力连接到某个 AI 员工实际可用的服务器、工具和凭证。
这样做的目的不是多一层配置，而是防止把业务口径、执行协议、系统地址和密钥混在同一个资产里。
一、从“会说话”到“能办事”
客户会问产品介绍、常见问题，也会提出必须依赖真实系统的问题：
今天还有库存吗？
帮我查一下订单进度。
可以约本周末吗？
这个问题请转给人工处理。
前一类问题主要依赖 FAQ、RAG 知识库、客户表达和业务政策；后一类问题还需要读取或写入业务系统。
V2 的原则是：模型负责根据已发布资产理解语义、选择候选能力；资产声明能力空间与边界；运行态只校验、执行和记录。
因此，运行代码不应写“客户问订单就调用订单工具”这类业务规则。它只执行资产已经声明、且当前 AI 员工已经绑定并获准使用的能力。
二、V2 的完整分层
其中“引用”和“绑定”是两种不同关系：
| 层级 | 解决的问题 | 例子 |
|---|---|---|
| 系统基础资产 | 可复用的通用定义 | sys_first_seen_contact、通用能力契约、记录结构 |
| 组织任务包 | 一个能力单元如何工作 | 查订单、创建预约、创建人工跟进 |
| 组织业务包 | 为某业务组合哪些任务和口径 | 安装预约任务、配置 FAQ/RAG、允许哪些能力 |
| AI 员工实例 | 这个员工实际上能连接和使用什么 | 绑定哪套 MCP 服务、哪个工具、哪份凭证 |
系统基础资产以 sys_ 开头，是共享且只读的 live 定义；组织不需要复制它们。组织在自己的任务包、业务包和 AI 员工实例中引用或绑定它们。
三、旧“Skill”在 V2 中对应什么？
“Skill”仍可作为产品语言，表示一个可复用能力边界，但它不再是把“破冰、异议、成交”这类话术标签堆在一起的配置对象。
在 V2 中，用户可运营的能力主要落在技能；任务包内部再引用一个或多个能力契约。
| 概念 | V2 对应物 | 应该承载的内容 | 不应该承载的内容 |
|---|---|---|---|
| 可复用业务能力 | task_asset_package |
任务目标、能力绑定、数据/旅程/控制/事件/Eval 契约 | 某行业的价格、承诺、客户话术 |
| 原子操作或查询 | capability_contract |
何时使用、何时禁止、输入、结果、读写影响、守卫与授权 | “客户问退款就选我”之类的运行时业务路由 |
| 怎么对客户说 | 业务包的表达、回复包、硬模板 | 口吻、固定通知、候选回复资产 | 把回复包装成伪能力 |
| 业务口径和限制 | business_policy |
可承诺/不可承诺、人工交接边界 | 工具地址、凭证、调用代码 |
如果两种配置的区别只是“说法不同”，应使用回复资产或业务政策；只有输入、输出、执行结果或风险边界不同，才应新增任务或能力契约。
reply 与 operation 的区别
V2 仍区分两种运行形态：
- reply：帮助模型在已知业务边界内组织回复，不产生外部副作用。
- operation：查询或执行动作，可能读取实时数据、写入业务系统、产生事件或创建任务。
这不是话术分类。它决定是否需要参数完整性、能力许可、确认、幂等、审计和失败处理。
例如“解释预约规则”是回复问题；“创建预约”是写操作。前者可以由知识与政策回答，后者必须通过任务包中的能力契约和 AI 员工的 MCP 资源绑定。
四、任务包：把能力组织成可完成的工作
任务包不是一张工具清单。它定义一个完整的可复用工作单元，例如“订单状态查询”“预约创建”或“人工跟进任务创建”。
一个 V2 任务包通常包含：
task_contract：任务要完成什么、何时适用。semantic_context：模型理解任务所需的最小业务上下文。data_contract：需要收集和维护哪些事实、数据结构是什么。capability_bindings：可以使用哪些能力契约。journey_contract：允许的阶段与完成条件。event_contract：订阅和发出哪些事件。control_contract：确认、授权、幂等和风险控制。eval_contract：如何回放并验证任务没有退化。
业务包通过 task_installations 安装任务。安装只是在业务组合层启用任务，不复制任务本体，更不会复制系统基础资产。
这带来一个清晰的维护方式：
- 想让 AI 员工新增退款处理能力：安装或创建退款任务包。
- 想让它在已有任务里改口径：修改业务包的政策、表达、知识配置或权限。
- 想让它连接另一套订单系统：修改 AI 员工实例资源绑定，而不是改任务定义。
五、能力契约：先声明“能不能做”，再调用工具
能力契约是 V2 的原子执行边界。一个契约至少说明：
semantics.use_when：什么情况下适合使用。semantics.not_when：什么情况下不能使用。arguments：调用所需的语义参数和系统参数。effect：这是只读查询还是写操作。guards与authorization：必须满足的通用安全条件。result：返回结果怎样归类、怎样投影、失败时如何处理。presentation_policy：结果是固定通知还是由模型在约束下表达。
模型可以在候选范围内选择能力，但不能跳过这些约束。尤其是写操作，未知结果默认 fail-closed；缺少参数、确认、前置条件或授权时，运行态不会执行。
例如，预约能力不是“只要出现预约二字就调用”。它由任务和能力契约共同声明：需要哪些事实、何时向客户确认、怎样避免重复创建、成功或失败后产生什么事件。
六、Tool：执行实现，不是业务决策入口
Tool 是能力契约背后的具体执行实现。它可以是平台内置工具，也可以是通过 MCP 暴露的企业系统工具。
V2 的调用顺序是：
- 业务包与任务包给出当前可用的业务空间。
- 模型基于客户消息、已收集事实和资产上下文选择候选能力。
- 运行态校验能力契约、许可、参数、确认和幂等条件。
- 执行对应的 platform tool 或 MCP tool。
- 依据结果契约投影结果、触发事件，并生成受约束的回复。
所以不应把“工具名”当成业务配置，也不应在运行代码中根据行业、状态或意图硬选工具。工具只实现能力契约已经允许的动作。
七、MCP：资源接入与权限边界
MCP 是将企业业务系统能力提供给 AI 员工的协议和接入方式。它不等于业务包中的“某个工具开关”。
V2 把 MCP 分成两层：
| 层 | 资产/配置 | 负责什么 | 不放什么 |
|---|---|---|---|
| 资源要求 | mcp_requirement |
声明一组稳定的 capability_keys，作为任务需要的能力组 |
服务地址、账号、密码、令牌 |
| 实例绑定 | AI 员工资源配置 | 绑定 MCP 服务、实际工具、凭证与组织授权 | 行业政策、客户话术、任务流程 |
业务包只在自己的资源许可中允许已被任务声明的能力；它不能凭空加出一个能力。AI 员工实例再提供实际可连接的 MCP 服务与工具绑定。
因此，一项 MCP 能力真正可用至少要同时满足：
- 当前业务包已经安装引入它的任务。
- 任务包已经绑定对应能力契约。
- 业务包已经许可该能力所需的 MCP 要求。
- 当前 AI 员工已经绑定可用的 MCP 服务、工具和凭证。
- 本轮调用通过能力契约的参数、确认、守卫和授权校验。
任何一层缺失，模型都不应假装调用成功；运行记录必须明确说明是哪个边界阻止了执行。
八、知识、政策、回复资产与 MCP 的边界
不要把所有内容都塞进知识库，也不要用一条业务政策去伪装一个缺失的任务能力。
| 用户问题 | 正确的 V2 资产路径 |
|---|---|
| “产品有什么功能？” | FAQ/RAG、回复资产、业务政策 |
| “现在还有没有库存？” | 库存查询任务 + 只读能力契约 + MCP 绑定 |
| “帮我改订单地址” | 订单任务 + 写能力契约 + 许可、确认、幂等 + MCP 绑定 |
| “请人工跟进” | 人工跟进任务 + 任务创建能力；不应只写一句回复政策 |
| “第一次会话要主动问候” | sys_first_seen_contact 事件 + 业务包允许的固定表达/回复资产 |
可以用一句话记住：
- 知识回答“资料里怎么说”。
- 政策回答“什么可以承诺、什么必须拒绝或转人工”。
- 回复资产回答“这句话怎样稳定地表达”。
- 任务和能力回答“现在能完成什么业务动作”。
- MCP 实例绑定回答“这个 AI 员工此刻实际连得上什么系统”。
九、示例：订单状态查询
客户说：
帮我查一下订单现在到哪里了。
V2 不会直接按关键词调用工具，而是这样运行：
- 业务包提供订单查询所需的业务口径与已安装任务。
- 订单状态查询任务声明需要订单标识，以及可使用的查询能力。
- 能力契约判断这是只读查询，校验订单标识是否完整。
- 如果订单标识不足，模型在任务边界内追问；如果完整，运行态检查 MCP 许可和 AI 员工实际绑定。
- MCP 工具返回结构化结果；能力契约按声明的结果码和展示策略投影。
- Agent 基于真实结果回复客户；调用、参数摘要、结果和失败原因均进入 Trace。
如果客户改问“我要取消订单”，这不应复用查询能力。它需要另一项写能力、相应任务控制、明确确认与更严格的授权边界。
十、建设 V2 能力时的检查清单
新增一项业务能力前，按顺序检查：
- 这是新任务还是只是新说法？ 仅是表达差异，用回复资产或政策；能完成不同业务动作，建立/安装任务。
- 能力边界是否清晰？ 写明
use_when、not_when、参数、结果和读写影响。 - 是否需要 MCP？ 若需要，只声明
mcp_requirement；服务地址和凭证留在 AI 员工实例。 - 业务包是否许可？ 能力必须先由任务引入，再被业务包许可。
- 写操作是否可控？ 必须有确认、前置条件、幂等和失败闭环。
- 是否能回归验证？ 为关键成功、拒绝和失败场景补充 Eval，并观察运行 Trace。
结语
V2 的重点不是给 Agent 堆更多“技能”和“工具”，而是让每一种能力都有正确的归属：
- 任务包定义可复用的工作单元；
- 能力契约定义可执行的安全边界；
- 业务包组合任务与业务口径；
- AI 员工实例绑定真实的 MCP 资源；
- Trace 和 Eval 让每次执行可解释、可验证、可持续改进。
这样，AI 员工才能既会聊天，也能在可控范围内真正办成事。