V2 资产逻辑：从团队资产到线上 AI 成员
这篇说明当前 V2 的资产概念和边界。它适合在新建、修改或排查 AI 员工前阅读。
当前系统只运行 V2：线上行为来自已发布的 V2 资产和活跃的 AI 成员资源绑定。草稿仅用于编辑；历史记录仅用于审计，不能作为线上决策来源。
一、核心原则
V2 用一句话概括：
资产声明业务空间和边界，模型在边界内做语义判断，运行时负责校验、执行与留痕。
因此，配置的目的不是把“客户说 A 就走流程 B”写死，而是让业务以结构化、可发布、可回溯的方式说明：
- 哪些信息值得理解和保存；
- AI 能做哪些事、不能做哪些事；
- 哪些业务流程、事件和风险约束适用；
- 需要哪些知识和外部服务；
- 在什么业务方案下对客户沟通。
模型负责理解客户表达、选择合适的能力、生成事实候选和回复计划。运行时不会猜测新的业务规则；它只执行资产已经声明的候选召回、结构校验、风险门禁、工具调用、幂等控制、事件投递和审计。
二、四层对象
V2 将“业务定义”和“组织运行配置”分成四层：
| 层级 | 对象 | 负责什么 | 不负责什么 |
|---|---|---|---|
| 1 | 团队基础资产 | 可复用的能力、数据、事件、政策、表达和资源需求 | 某个岗位的业务编排、某个组织的实际连接信息 |
| 2 | AI 员工技能 | 一件可复用的完整工作，如答疑、留资、预约或查询 | 具体渠道、服务器、知识库 ID |
| 3 | AI 员工岗位 | 将技能组合为一个完整业务方案，并补充业务语境与默认要求 | 某个组织实际选用的 MCP 服务器或知识库 |
| 4 | 团队 AI 成员 | 绑定已发布岗位、实际资源、运行策略和接待账号 | 复制或临时改写业务规则 |
系统基础资产（sys_*，平台维护）
+ 组织基础资产（组织可维护）
↓
AI 员工技能（任务包）
↓
AI 员工岗位（业务包）
↓ 发布为可追溯的 V2 闭包
团队 AI 成员（实际资源绑定） + 接待账号（渠道接入）
↓
客户会话、运行记录与审计
四层对象回答的是“资产如何组合并上线”；十类基础资产分类仍然保留，回答的是“基础层里分别维护什么”。两者不是替代关系：十类基础资产被技能和岗位引用，最终由 AI 成员在组织内绑定实际资源并运行。
团队基础资产
入口：/builder/v2-assets/foundation
基础资产是跨技能、跨岗位复用的业务契约。当前仍按以下十类管理：
| 分类 | V2 资产 | 解决的问题 | | --- | --- | | 语义 | 客户表达 | 维护业务词汇、客户表达与可复用语义边界。 | | 政策 | 业务政策 | 声明不可违反的业务、合规与风险要求。 | | 能力 | 能力契约 | AI 可以查询或执行什么；读写边界、输入输出结构和风险限制是什么。 | | 资源 | MCP 要求 | 某一类能力需要什么服务能力组，而不是绑定某台服务器。 | | 数据 | 记录结构 | 定义结构化参数、事实与工具输入输出的值格式。 | | 数据 | 事实契约 | 定义哪些业务信息可以跨轮保存，以及保存边界。 | | 事件 | 事件 | 定义什么算一个业务事件、由谁产生及其治理边界。 | | 事件 | SOP | 定义事件发生后需要同步或异步完成的工作。 | | 表达 | 表达模板 | 维护必须稳定或可复用的表达内容与变量结构。 | | 表达 | 话术包 | 组织表达模板和候选回复的使用范围。 |
十类基础资产描述的是可复用边界。例如，案例查询能力可以说明支持按照行业和场景查询，但不应在这里写某个组织自己的案例库地址、账号或工具名；这些属于 AI 成员的实际资源绑定。
AI 员工技能
入口：/builder/v2-task-packages
技能是一个可复用的工作边界。它组合所需的能力、事实、旅程、事件消费者、风险约束和 Eval，用来完成一件完整的业务工作。
好的技能以工作结果命名，例如：
- 查询解决方案与案例；
- 收集预约信息；
- 解答产品使用问题；
- 创建或修改有审批要求的业务记录。
技能不是话术分类，也不是把某个行业的完整销售脚本塞进去。产品政策、行业术语和岗位语境应放在 AI 员工岗位；服务器、知识库和渠道应放在 AI 成员。
AI 员工岗位
入口：/builder/v2-assets/business
岗位是可运行的业务方案。它将多个技能组合起来，补充业务词汇、政策、表达策略、资源需求和默认 AI 成员蓝图。业务规则的主要归属是岗位和它引用的技能、基础资产，而不是运行时代码或单个 AI 成员配置。
例如，一个“产品激活顾问”岗位可以组合“方案与案例查询”“产品答疑”“预约协助”等技能，并声明需要案例查询 MCP、FAQ 与 RAG 知识；具体接哪一个组织服务、哪一份知识，则由创建后的 AI 成员选择和绑定。
团队 AI 成员与接待账号
入口：/builder/v2-agents、/robots
AI 成员是组织的运行实例。它选择一个已发布岗位，并绑定：
- 具体 FAQ 和 RAG 知识来源；
- 每一项 MCP 能力实际使用的服务和工具；
- 运行与审批策略；
- 接待账号和渠道。
AI 成员不拥有独立的业务语义。遇到回答、流程或工具选择问题时，应回溯到岗位、技能、基础资产、知识来源或资源绑定，修复对应源头。
三、资源要求与实际绑定
业务资源需求和实际资源绑定必须分开维护：
| 问题 | 在哪里定义 | 示例 |
|---|---|---|
| 业务需要什么能力或知识类型？ | 基础资产、技能、岗位 | “需要方案与案例查询能力组”“需要 RAG 知识” |
| 实际使用哪个服务、工具或数据集？ | 团队 AI 成员 | “使用本组织的案例库 MCP”“绑定产品文档 RAG 数据集” |
这种分离带来两个好处：同一个岗位可以在不同组织复用；组织可以替换知识库或 MCP 服务，而不必修改业务语义。
MCP 要求只声明能力组。AI 成员的资源绑定才决定实际 server 与 tool。知识也是同样的模式：岗位声明 FAQ/RAG 需求，AI 成员绑定实际题库和知识文档。
对于查询型 MCP，必须确保结果来自已绑定的服务；对于写入型 MCP，能力契约还必须声明结构、授权事件、守卫、幂等和结果边界。任何缺失均应拒绝执行，而不是由运行时猜测补齐。
四、发布和线上生效
V2 的线上版本不是草稿。一次标准生命周期是：
编辑组织草稿
→ Schema 与关系闭包校验
→ 发布不可变版本
→ AI 成员在下一轮解析当前已发布闭包
→ Session / Run / Trace 留存本轮实际版本与结果
发布会检查资产结构、引用完整性、任务与基础资产闭包、业务包装配、资源约束和默认蓝图归属。缺少引用、结构不匹配或资源要求无法满足时，发布必须失败，不能带病上线。
AI 成员保存的是稳定的岗位 key，而不是复制一份业务包内容。因此，成员会在后续处理时解析该岗位的最新已发布闭包；草稿从不会直接影响线上会话。
系统基础资产使用 sys_ key，由平台维护。组织资产可以在组织范围内使用或显式覆盖。系统组合资产需要先物化为组织可运行的资产，不能直接作为组织线上实例的临时替代。
五、一次客户消息如何运行
下面的顺序是理解运行和排查问题的关键：
客户消息进入接待账号
→ 找到绑定的团队 AI 成员
→ 装配该成员的已发布岗位闭包、会话事实和实际资源绑定
→ 模型进行语义理解、能力选择、事实候选与回复计划
→ 运行时执行结构校验、授权/风险门禁与工具调用
→ 写入事实、状态、事件和异步投递
→ 合成回复并记录 Run / Trace / 审计
这里没有“旧版意图路由配置”或“按关键字固定选话术”的线上入口。模型可在资产声明的候选空间内判断；运行时只负责可靠地阻止越界、执行已声明能力，并把证据写入追踪记录。
六、如何判断应该改哪里
| 现象 | 优先修改的位置 |
|---|---|
| 不知道应该理解或保存什么客户信息 | 事实契约、记录结构、客户表达或技能目标 |
| 没有合适的业务工作可执行 | 能力契约与 AI 员工技能 |
| 业务话术、行业语境或多技能协同不对 | AI 员工岗位及其引用资产 |
| 查不到知识或案例 | 知识中心/知识库配置、MCP 服务、AI 成员实际资源绑定 |
| 工具不该执行或高风险操作缺少控制 | 能力契约、业务政策、授权/审批与幂等约束 |
| 修改后线上没有变化 | 是否已发布；AI 成员是否绑定正确岗位；新 Run 是否使用了新闭包 |
| 需要替换组织服务或数据集 | 团队 AI 成员的资源绑定，不改岗位业务规则 |
优化时应先从运行追踪中查看本轮实际使用的岗位、资源和结果，再补充可复现的 Eval 场景，最后修改对应资产并发布。不要为了修复单个对话而把特定行业规则硬编码进运行时。
七、V2 的边界与常见误区
| 正确做法 | 常见误区 |
|---|---|
| 让岗位和技能声明业务边界，让模型在边界内判断 | 用规则、关键词或运行时代码替模型选择业务动作 |
| 让岗位声明“需要什么资源” | 在岗位中写服务器地址、工具名、密钥或知识库 ID |
| 让 AI 成员绑定本组织的实际资源 | 在 AI 成员中临时改写行业政策和业务流程 |
| 保存后完成预检并发布 | 把草稿当作已经生效的线上版本 |
| 用 Trace、Eval 和审批记录定位问题 | 只凭一次客户回复修改提示词或绕开审批 |
| 新能力直接以 V2 资产和绑定实现 | 回退、复用或新增 V1 资产、模板、Agent 或绑定 |
八、动手前检查清单
- [ ] 这项内容是可复用基础契约、可复用技能、业务岗位，还是组织运行配置？
- [ ] 业务规则是否落在岗位、技能或基础资产，而不是 AI 成员或运行时代码？
- [ ] 是否把资源需求与实际资源绑定分开？
- [ ] MCP 查询或写入能力是否有清晰的输入输出、风险和授权边界？
- [ ] 所有引用资产是否已发布并能通过闭包校验？
- [ ] 是否为关键业务场景准备了 Eval 和上线后的 Trace 观察？
- [ ] 是否只使用 V2 资产、V2 AI 成员和 V2 渠道绑定？