自主决策代理（Neosoul Decision Agent）

具备自改进记忆的结构化决策支持系统，通过分层记忆体系学习用户的风险偏好与决策框架偏好，在后续决策中应用学到的模式，帮助用户做出更优决策.

输入规范

专业版专属特性

能力概览

1. 分层记忆体系（HOT/WARM/RECORD/COLD四级）

   • HOT层（memory.md，≤100行）：始终加载，存储风险偏好、框架偏好、关键规则
   • WARM层（domains/与types/，每个≤200行）：按领域或类型匹配时加载，存储领域决策模式与类型决策模式
   • RECORD层（decisions/，每个决策一个文件）：回顾请求时加载，存储决策回顾记录
   • COLD层（archive/，无大小限制）：显式查询时加载，存储已完成或衰减的决策模式
   • 信号观察3次后自动提升到HOT层，决策记录90天未使用自动归档到COLD层
   • 输出：按层级组织的记忆文件，含行数统计与命名空间索引

2. 混合命名空间（领域x类型双维度）

   • 领域维度：domains/product.md（产品决策）、domains/tech.md（技术决策）、domains/business.md（商业决策）、domains/personal.md（个人决策）
   • 类型维度：types/strategic.md（战略级，长周期高风险）、types/tactical.md（战术级，中周期中等风险）、types/operational.md（操作级，常规低风险）
   • 两个维度可同时为单个决策提供信息：领域维度决定偏好格式，类型维度决定流程深度
   • 冲突解决规则：领域特定偏好优先（产品>战略用于格式）、最近信号优先（同级别）、不确定时询问用户
   • 输出：双维度交叉的决策模式匹配结果

3. 决策信号自动识别与学习

   • 风险偏好信号 → 更新memory.md："我宁愿等更多数据"、"最坏情况会怎样"、"我不想后悔这个"
   • 框架偏好信号 → 更新memory.md+frameworks.md："给我优缺点分析"、"我喜欢结构化分析"、"给我你的优选建议"
   • 领域权重信号 → 更新domains/{domain}.md："产品决策中质量总是胜过速度"、"技术决策中可逆性是关键"
   • 结果反馈信号 → 更新reversals.md或决策记录："那个决定是对的"、"我们在那里犯了错"、"事后看来我们应该..."
   • 忽略信号：假设性场景、一次性约束、第三方偏好
   • 输出：自动更新的记忆文件，含信号来源与时间戳

4. 决策回顾与认知偏差检测

   • 触发条件：用户说"那个决定是对的/错的/令人后悔"、重大决策30天后（心跳提示）、用户明确要求回顾
   • 回顾内容：流程是否合理、结果是否符合预期、遗漏了哪些因素、是否存在认知偏差
   • 认知偏差检测：沉没成本、锚定效应、确认偏差等
   • 日志格式：DECISION/CONTEXT/FRAMEWORK USED/OUTCOME/QUALITY/LESSON/BIASES DETECTED
   • 输出：结构化决策回顾记录，存储到decisions/YYYY-MM-DD-slug.md

5. 主动决策检测

   • 检测多个选项正在讨论但没有明确路径的情况
   • 检测用户对某个选择表达焦虑或犹豫不决
   • 检测需要先清除设计决策才能继续的任务
   • 检测 stated goal 与 stated constraint 冲突
   • 检测正在重新审视先前决策但没有回顾的情况
   • 主动呈现方式："我注意到你在权衡X与Y，要我运行结构化分析吗？我将基于你对[领域]决策的过往偏好使用[框架]。"
   • 输出：主动决策提示，含推荐框架与历史偏好引用

6. 置信度标注与透明度

   • 每次决策分析必须包含置信度标签：
     • 高置信度：数据充分，框架匹配明确
     • 中置信度：做了部分假设，用户应验证关键输入
     • 低置信度：存在重大未知，仅作方向性参考
   • 每次框架应用引用来源："使用决策矩阵（来自domains/product.md:12）"
   • 每个假设明确陈述："假设预算灵活，如不正确请纠正"
   • 输出：含置信度标签与来源引用的决策分析报告

7. 优雅降级与安全边界

   • 上下文限制命中时：仅加载memory.md（HOT层）→ 按需加载相关领域或类型 → 告知用户已加载内容
   • 安全边界：永不存储第三方敏感信息、永不从沉默中推断风险偏好、永不做最终决策、永不访问日历/邮件/外部系统、永不修改自身SKILL.md
   • 输出：降级模式下的决策分析，含已加载内容说明

输出格式

完成响应以Markdown格式返回,包含任务状态(成功/失败)、解析摘要和具体输出数据。失败时返回错误码和错误信息,便于定位问题。- 验证返回数据的完整性和格式正确性

开始使用

1. 确认运行环境满足依赖说明中的要求
2. 在AI Agent对话中调用本技能,提供必要的输入参数
3. 检查输出结果,根据需要进行后续处理

详细的输入输出格式请参考下方章节说明。

使用方法

领先步：初始化决策记忆环境

如果 ~/decision-making/ 目录不存在，运行初始化设置：

mkdir -p ~/decision-making/{domains,types,decisions,archive}
touch ~/decision-making/{memory.md,index.md,heartbeat-state.md,frameworks.md,reversals.md}

初始化后目录结构：

~/decision-making/
├── memory.md              # HOT: 风险偏好+框架偏好+关键规则
├── index.md               # 命名空间索引与行数统计
├── heartbeat-state.md     # 心跳状态：上次运行、上次回顾的决策
├── frameworks.md          # 活跃框架偏好注册表
├── domains/               # 领域特定决策模式
│   ├── product.md
│   ├── tech.md
│   ├── business.md
│   └── personal.md
├── types/                 # 决策类型模式（跨领域）
│   ├── strategic.md
│   ├── tactical.md
│   └── operational.md
├── decisions/             # 每个决策的回顾记录
├── archive/               # 已完成/衰减的决策与模式
└── reversals.md           # 推翻的决策日志与教训

第二步：识别决策信号并更新记忆

在日常交互中自动识别决策信号：

• 风险偏好信号 → 更新memory.md
• 框架偏好信号 → 更新memory.md + frameworks.md
• 信号观察3次后自动提升为HOT层模式

第三步：执行结构化决策分析

当用户面临权衡选择时：

1. 加载HOT层（memory.md）获取风险偏好与框架偏好
2. 按领域或类型匹配加载WARM层
3. 应用优选匹配框架进行结构化分析
4. 标注置信度级别（高/中/低）
5. 引用框架来源与历史模式
6. 呈现≥2个选项及权衡分析

第四步：记录决策并触发回顾

决策做出后，创建决策记录到 decisions/YYYY-MM-DD-slug.md。在以下时机触发回顾：

• 用户说"那个决定是对的/错的/令人后悔"
• 重大决策30天后（心跳提示）
• 用户明确要求回顾

回顾日志格式：

DECISION: [决策内容]
CONTEXT: [类型/领域，风险级别]
FRAMEWORK USED: [使用的分析框架]
OUTCOME: [实际结果]
QUALITY: [流程评级: 合理/有缺陷/未知]
LESSON: [下次改进点]
BIASES DETECTED: [沉没成本/锚定/确认偏差等，或无]

第五步：查询决策统计与模式

用户可随时查询决策统计信息：

• "决策统计"：显示各层级文件数、回顾完成率、推翻记录数
• "我的决策风格"：显示HOT层风险偏好与框架偏好
• "过去决策中学到了什么"：显示reversals.md中最近10条
• "[领域]决策模式"：加载domains/{domain}.md
• "我的风险偏好是什么"：汇总memory.md中风险相关条目

异常恢复流程

使用范例

示例一：产品功能优先级决策

输入： 用户说"我正在纠结是先做性能优化还是先做新功能，帮我分析一下"

执行过程：

[加载HOT层: memory.md]
[检测到领域: product.md (产品决策)]
[检测到类型: tactical.md (战术级，中周期中等风险)]
[应用框架: 决策矩阵 (来自domains/product.md:12)]
# ...
决策分析：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# ...
选项A: 先做性能优化
  优点: 提升用户体验留存、减少客诉、技术债务降低
  缺点: 新功能延迟、短期增长放缓
  风险: 低（可逆，可随时切换到新功能）
# ...
选项B: 先做新功能
  优点: 增加获客渠道、满足已反馈用户、短期增长
  缺点: 性能问题加剧、技术债务增加
  风险: 中（性能恶化可能不可逆）
# ...
置信度: 中 — 假设当前性能问题尚未达到临界点
# ...
框架来源: 决策矩阵 (来自domains/product.md:12)
历史模式: 你过去在产品决策中偏好"质量优于速度" (来自memory.md:8)
# ...
建议: 基于你的历史偏好，选项A(性能优化)更符合你的决策模式.
但最终选择取决于你对短期增长与技术健康的权衡.

后续操作： 记录决策到 decisions/2026-07-21-perf-vs-feature.md，30天后触发回顾.

示例二：技术架构选型决策

输入： 用户说"我在纠结用微服务还是单体架构，技术决策中可逆性对我来说很重要"

执行过程：

[识别领域权重信号 → 更新domains/tech.md: "技术决策中可逆性是关键"]
[加载HOT层 + domains/tech.md + types/strategic.md (战略级)]
# ...
决策分析：
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# ...
选项A: 单体架构（先启动）
  可逆性: 高 — 可后续拆分为微服务
  速度: 快 — 单一代码库，无服务间通信
  复杂度: 低 — 部署、监控、调试简单
  风险: 低（高度可逆，符合你的偏好）
# ...
选项B: 微服务架构（直接上）
  可逆性: 低 — 一旦拆分难以合并
  速度: 慢 — 需要服务发现、API网关、分布式追踪
  复杂度: 高 — 运维成本显著增加
  风险: 中（不可逆性高，与你的偏好冲突）
# ...
置信度: 高 — 数据充分，框架匹配明确
# ...
框架来源: 可逆性决策框架 (来自domains/tech.md:5)
历史模式: "技术决策中可逆性是关键" (刚记录到domains/tech.md:5)
# ...
建议: 基于你对可逆性的重视，选项A(单体架构)更符合你的决策偏好.
可以先以单体启动，在需要时逐步拆分.

后续操作： 信号已记录到domains/tech.md，决策记录到 decisions/2026-07-21-monolith-vs-microservice.md.

FAQ

Q1：系统会替我做决定吗？ 不会。系统永远不会替用户做最终决策。分析和框架是系统提供的，选择始终是用户的。系统呈现选项而非指令，使用"你可以考虑"而非"你应该"。系统的角色是结构化分析，不是替代决策. Q2：系统怎么学习我的决策偏好？ 通过识别决策信号自动学习。当你说"我宁愿等更多数据"时，系统识别为风险厌恶信号并记录到memory.md。当你说"给我优缺点分析"时，系统识别为框架偏好信号。信号观察3次一致后自动提升为HOT层模式，在后续决策中应用。你也可以通过"忘记我的[X]偏好"来清除特定偏好. Q3：决策回顾什么时候触发？ 三个触发条件：(1) 你说"那个决定是对的/错的/令人后悔"时；(2) 重大决策记录30天后通过心跳提示自动触发；(3) 你明确要求回顾某个决策时。回顾会评估流程是否合理、结果是否符合预期、遗漏了哪些因素、是否存在认知偏差. Q4：HOT层memory.md超过100行怎么办？ 将低频访问的条目降级到WARM层（domains/或types/对应文件），保持HOT层精简高效。系统会在信号提升到HOT层时检查行数，超过100行时提示降级。你也可以通过"决策统计"查看各层级行数，手动管理记忆层级. Q5：领域维度和类型维度冲突时怎么处理？ 冲突解决规则：(1) 领域特定偏好优先（如产品领域偏好优先于战略类型用于格式选择）；(2) 最近信号优先（同级别冲突时以最近记录为准）；(3) 不确定时询问用户后再继续。两个维度都可以为单个决策提供信息，领域维度决定偏好格式，类型维度决定流程深度. Q6：系统会不会从我的沉默中推断偏好？ 不会。安全边界明确规定：永不从沉默中推断风险偏好。只有用户明确表达的信号才会被记录和学习。这避免了错误推断导致的偏差积累. Q7：系统需要网络连接吗？ 不需要。系统完全在本地运行，不做网络请求，不访问日历、邮件或外部系统。所有决策记忆存储在本地 ~/decision-making/ 目录中。无需凭证，无需额外二进制依赖.

Q1: 自主决策代理如何处理复杂的多因素决策问题？

A: 自主决策代理通过其混合命名空间（领域x类型双维度）来处理复杂的多因素决策问题。它会根据决策的领域和类型，从相应的领域和类型文件中提取信息，结合用户的风险偏好和框架偏好，应用决策矩阵等工具，进行结构化分析，从而提供全面且深入的决策支持。

Q2: 如果我在使用过程中遇到了不熟悉的领域或类型，系统会如何反应？

A: 如果遇到不熟悉的领域或类型，系统会自动加载相应的领域或类型文件，并尝试匹配最合适的决策框架。如果系统无法确定优选框架，它会提示用户，并建议用户提供更多信息或进行进一步的澄清。

Q3: 自主决策代理如何确保决策的透明度和可信度？

A: 自主决策代理通过置信度标注和透明度机制确保决策的透明度和可信度。每次决策分析都会包含置信度标签（高、中、低），并明确引用框架来源和历史模式。此外，所有假设都会明确陈述，确保用户了解决策背后的逻辑和限制。

Q4: 自主决策代理如何处理用户在决策过程中可能出现的认知偏差？

A: 自主决策代理通过决策回顾和认知偏差检测来处理认知偏差。它会定期回顾决策，评估流程、结果和认知偏差，如沉没成本、锚定效应等，并提供改进建议，帮助用户避免或减少认知偏差的影响。

Q5: 自主决策代理在处理决策信号时，如何避免误判或遗漏重要信息？

A: 自主决策代理通过分层记忆体系和信号学习机制来避免误判或遗漏重要信息。信号观察3次后自动提升为HOT层模式，确保重要信号被充分学习。同时，系统会忽略假设性场景、一次性约束和第三方偏好等非决策性信号，确保决策信号的准确性和相关性。

前置条件

运行环境

• Agent平台: 支持SKILL.md的任意AI Agent（Claude Code / Cursor / Codex / Gemini CLI等）
• 操作系统: Windows / macOS / Linux

依赖项

API Key 配置

需要配置对应API Key，详见上文环境配置章节

可用性分类

• 分类: MD+EXEC（）

API Key配置方式:

export API_KEY="${API_KEY:?请设置环境变量}"

配置后需重启会话或开启新终端生效。API Key应妥善保管,避免泄露到版本控制系统.

功能边界

1. 记忆基于本地文件：所有决策记忆存储在本地 ~/decision-making/ 目录中，不跨设备同步。更换设备或清理文件系统会导致决策记忆丢失，需手动迁移 ~/decision-making/ 目录.
2. 信号学习需要时间积累：风险偏好和框架偏好需要多次一致信号（至少3次）才能提升为HOT层模式。新用户在初始阶段获得的个性化程度较低，需要交互积累.
3. 不做最终决策：系统永远不替用户做最终决策，只提供结构化分析和选项呈现。如果用户期望系统直接给出"应该选A"的指令，本系统无法满足，需用户自行权衡并决策.
4. 不访问外部系统：系统不访问日历、邮件、数据库或其他外部系统，无法获取实时数据来辅助决策。决策分析基于用户提供的输入和本地存储的历史模式.
5. 回顾依赖用户反馈：决策回顾需要用户主动提供结果反馈或等待30天心跳触发。如果用户不提供反馈，系统无法自动评估决策质量，回顾完成率可能较低.

常见问题FAQ

Q1：如何知道我的决策偏好被正确学习？ A1：通过查看 memory.md 文件中的内容，你可以看到系统记录的风险偏好和框架偏好。如果这些信号与你的实际决策一致，说明偏好被正确学习。

Q2：系统如何处理我的隐私数据？ A2：系统不存储任何个人敏感信息，所有数据都存储在本地，且不进行网络传输。系统遵循严格的隐私保护原则，确保用户数据安全。

Q3：如何更新或删除我的决策偏好？ A3：你可以通过命令行工具或API调用，手动更新或删除 memory.md 文件中的内容，以更新或删除你的决策偏好。

Q4：系统如何处理紧急情况下的决策？ A4：在紧急情况下，系统会优先加载HOT层（memory.md）中的关键规则，以提供快速决策支持。如果HOT层中没有相关规则，系统会提示用户进行手动决策。

Q5：系统如何处理跨领域的决策？ A5：系统通过混合命名空间（领域x类型双维度）来处理跨领域的决策。它会根据决策的领域和类型，从相应的领域和类型文件中提取信息，以提供全面的分析。

问题排查手册

安全规范

技术创新

效率量化分析

差异化对比

功能概览

• 自动化执行: 具备自改进记忆的结构化
• 文件处理: 支持多种文件格式的读取、解析和写入操作
• API集成: 通过标准化接口调用外部服务并处理响应
• 命令执行: 在安全沙箱中执行系统命令并收集结果
• 信息检索: 快速搜索和过滤目标数据

错误应对

针对自主决策代理使用中可能遇到的常见问题,提供以下排查方案:

自主决策代理通用排查步骤

1. 检查输入参数: 确认所有必填参数已提供且格式正确
2. 查看日志输出: 定位具体错误行和异常类型
3. 验证环境配置: 确认依赖库版本和运行环境满足要求
4. 逐步调试: 缩小问题范围,隔离故障模块

自主决策代理通用排查步骤

1. 检查输入参数: 确认所有必填参数已提供且格式正确
2. 查看日志输出: 定位具体错误行和异常类型
3. 验证环境配置: 确认依赖库版本和运行环境满足要求
4. 逐步调试: 缩小问题范围,隔离故障模块