实现范围
前面三篇已经把架构边界、领域模型和运行保障梳理完整。真正落到代码时，我们不需要一次实现所有设计，而是先明确第一阶段的范围。
共享 Zod 契约先把 Manifest、Scope、Kind 和 Selection 固定下来，静态 Registry 只注册经过代码审核的内置 Skill。聊天请求到来后，确定性 Selector 从用户消息中选择最多一个 Skill，再把 Prompt Skill 的过程指令注入单聊和群聊的回复生成。第一阶段的闭环就是这样建立起来的。
数据库迁移、用户开关、Skill Session、运行日志、工具调用、后台任务和管理页面都不在这一阶段处理。
代码目前集中在共享契约和 API 运行时两个位置：
共享契约放在 @repo/contracts，方便未来 Web 管理页、API、数据库模型和运行时使用同一份结构。匹配器和完整 Prompt 指令属于服务端实现细节，不进入公共契约。
第一阶段实现的 Manifest 字段包括：
| 字段 | 作用 |
|---|---|
id | 稳定的短横线命名标识 |
version | 当前 Skill 的语义化版本 |
name | 展示名称 |
description | 能力和边界的简短说明 |
kind | 运行类型，当前 Registry 只接受 prompt |
scopes | 允许在单聊或群聊中运行 |
triggerExamples | 示例触发语句 |
priority | 同分候选的稳定排序依据 |
enabledByDefault | 是否默认启用 |
Manifest 已预留 workflow、tool 和 background 类型，但第一阶段 Registry 会拒绝非 prompt 定义。预留类型用于稳定架构方向，不代表当前已经授予执行权限。
Registry 在模块加载时执行 Zod 校验，并检查重复 ID。错误配置会尽早失败，而不是在用户聊天中随机暴露。
选择算法
第一阶段没有为了选择 Skill 再增加一次 LLM 调用。整个选择过程依赖可复现的规则：
- 规范化当前用户消息。
- 检查
/decision-clarifier或/skill decision-clarifier形式的显式命令。 - 按当前单聊或群聊 Scope 过滤 Registry。
- 每命中一个正则语义模式计 6 分。
- 每命中一个关键词计 2 分，关键词总分最多 8 分。
- 自动选择阈值为 4 分。
- 按得分、Manifest 优先级和稳定 ID 排序。
- 只选择第一名。
第一阶段有意把范围限制为单轮只运行一个 Skill。这样可以避免主动倾听、决策分析和目标拆解同时向模型发出互相竞争的过程要求。
内置 Skill
结合电子伴侣当前最常见的使用场景，第一阶段先内置四个 Skill。
主动倾听 active-listening
它适用于用户明确想倾诉、暂时不要建议，或者表达明显的难过、孤独、委屈和混乱。回复时要先复述正在发生的事情与情绪，再给出具体、克制的确认。用户只想倾诉时不要主动提供方案，每次最多追问一个容易回答的问题，同时禁止心理诊断和依赖性表达。
决策澄清 decision-clarifier
它适用于选择、纠结、利弊和要不要一类的问题。我们先帮助用户明确真正要决定的问题和选项，再识别硬约束、偏好、可逆性与最坏结果。信息不足时，只追问那个最有可能改变判断的问题；信息足够以后，可以给出有依据的方向，但不替用户做最终决定，并尽量补充一个低成本验证动作。
目标拆解 goal-breakdown
它适用于计划、目标、第一步和无从下手的问题。处理时先把模糊目标改写为可以观察的结果，再识别关键约束，整理出三到五个有顺序的动作。回复里还要明确用户现在就能完成的最小第一步，并设置容易检查的节点，不要额外制造复杂的管理负担。
群聊圆桌 group-roundtable
它只允许在群聊运行，也不会替代现有 Agent 选择图。每个被选中的 Agent 只贡献一个与自身角色匹配的视角，先表达观点，再补充少量理由。回复时要避免复述问题，也不要重复其他 Agent 已经讲过的内容，还要给群内其他成员保留表达空间。
单聊与群聊接入
单聊原有流程为：
1安全分析2-> 意图、情绪、关系阶段与回复策略3-> 生成回复4-> 保存消息、记忆和摘要
Skill 解析放在安全边界提前返回之后。需要拒绝、重定向或危机支持时，系统直接返回原有边界响应，不执行 Skill。
进入正常回复以后，Skill 指令放在回复策略之后、反馈和长期记忆之前。我们可以把完整的提示词拼装顺序梳理为：
1Agent 人设2-> 全局回复和安全要求3-> 意图、情绪、关系阶段4-> 本轮回复策略5-> Skill 过程指令6-> 用户反馈偏好7-> 长期记忆和对话摘要
Skill 指令本身再次声明：它的优先级低于安全边界、Agent 人设、用户明确要求和既有回复策略，并且不能向用户暴露内部 Skill 名称、规则和分数。
群聊继续使用现有 LangGraph 完成意图分类、情绪判断、Agent 选择、回复生成、Agent 间回复和质量检查。
Prompt Skill 在 Agent 已经选中后，根据用户原始消息解析，并注入每个被选中 Agent 的主回复。简短的 Agent 间交叉回复不会再次完整执行 Skill，避免同一轮方法被重复放大。
现阶段每个 Agent 会得到同一个 Skill 过程目标，但仍然使用自己的角色 Prompt、语气、背景和长期记忆。等共享 SkillRun 实现以后，我们再进一步为不同 Agent 分配明确的圆桌角色。
请求流程
沿着单聊与群聊的接入逻辑走一遍，就能看到第一阶段的请求是怎样进入 Skill，再回到原有回复流程的：
假设用户输入：
1我在两个工作机会之间很纠结，不知道怎么选。
decision-clarifier 会命中选择模式和相关关键词，成为本轮 Skill。生成出来的回复会采用决策澄清过程，但 Agent 的人格、安全、记忆和关系阶段不会改变。
用户也可以显式启用：
1/goal-breakdown 帮我把准备考试拆成第一周的行动。
显式选择得分固定为 100，但仍会检查 Skill 是否启用、是否允许当前聊天场景。单聊显式请求群聊专用的 /group-roundtable 不会执行。
限制与验证
第一阶段限制
目前所有内置 Skill 都默认全局可用，还没有用户、Agent 和群聊 Binding。系统也没有 Skill Session，多轮任务不会保存独立的结构化状态；没有 SkillRun，意味着选择结果只存在于当前请求；管理 API 和 Web 配置页面同样还没有实现。
选择器暂时不使用向量召回或 LLM 语义路由，规则需要根据真实样本继续调整。单轮只能选择一个 Skill，非 Prompt 类型虽然已经出现在枚举中，但还没有对应运行器，也没有任何执行权限。
这些限制都与前面的演进路线一致，并不是实现时遗漏了功能。第一阶段要先验证低风险 Prompt Skill 的选择是否稳定、回复方式是否真的得到改善。
手工验证
根据仓库约定，本次实现不自动运行测试、构建或浏览器检查。我们可以用下面这些消息把主要分支手工走一遍：
| 场景 | 示例 | 预期 |
|---|---|---|
| 普通聊天 | 今天午饭吃了面。 | 不启用 Skill，行为保持不变 |
| 主动倾听 | 你先听我说，别急着给建议。 | 先回应感受，不直接给方案 |
| 决策澄清 | 两个工作机会我很纠结，帮我分析利弊。 | 对称梳理选项和关键取舍 |
| 目标拆解 | 我想学英语但无从下手，帮我做个计划。 | 给出少量有顺序步骤和最小第一步 |
| 群聊圆桌 | 大家分别从不同角度说说看法。 | 多个角色观点有区分度、减少重复 |
| 显式启用 | /decision-clarifier 我该不该换工作？ | 优先启用指定 Skill |
| 场景限制 | 单聊输入 /group-roundtable ... | 不执行群聊专用 Skill |
| 安全边界 | 输入会触发原安全响应的内容 | 直接走原安全响应，不运行 Skill |
下一步
接下来先不要急着开发 Tool Skill。我们更需要为 Selector 建立包含正例、负例、冲突例和安全例的评测集，再用真实聊天样本调整触发规则与优先级。与此同时，可以增加最小 SkillRun 记录，开始观察命中率、误触发和用户反馈；等这些数据稳定下来，再增加用户、Agent 和群聊 Binding，让 Skill 真正可以被配置和关闭。
完成这些基础后，才能有足够证据决定哪些能力值得升级为有状态 Workflow，哪些只是需要更好的 Prompt Skill。
总结
把代码重新梳理一遍以后，第一阶段的边界就非常清楚了。我们用共享 Zod 契约、静态 Registry 和确定性 Selector 建立最小 Prompt Skill 闭环，四个内置 Skill 分别覆盖主动倾听、决策澄清、目标拆解和群聊圆桌，单轮只选择一个 Skill，避免过程指令互相竞争。
Skill 解析始终位于安全边界之后，单聊和群聊也继续复用原有理解、Agent 选择与质量检查流程。这个阶段暂时不引入 Binding、SkillSession、SkillRun、语义路由和高权限工具，接下来先通过评测集、真实聊天样本和运行记录验证选择效果，再决定哪些能力值得继续升级。