Install
openclaw skills install @thcjp/neosoul-decision-agentopenclaw skills install @thcjp/neosoul-decision-agent具备自改进记忆的结构化决策支持系统,通过分层记忆体系学习用户的风险偏好与决策框架偏好,在后续决策中应用学到的模式,帮助用户做出更优决策.
| 参数名 | 类型 | 必填 | 说明 |
|---|---|---|---|
| input | string | 是 | 自主决策代理处理的输入数据或指令 |
| options | object | 否 | 附加配置选项,如模式选择、格式偏好等 |
| callback_url | string | 否 | 异步处理完成后的回调通知URL |
| 能力 | 免费版 | 付费版 |
|---|---|---|
| 基础功能 | 支持 | 支持 |
| 复杂工作流可视化编排 | 不支持 | 支持 |
| 条件分支与异常重试 | 不支持 | 支持 |
| 定时触发与事件驱动 | 不支持 | 支持 |
| 执行日志与审计追踪 | 不支持 | 支持 |
| 分布式任务调度与负载均衡 | 不支持 | 支持 |
分层记忆体系(HOT/WARM/RECORD/COLD四级)
混合命名空间(领域x类型双维度)
决策信号自动识别与学习
决策回顾与认知偏差检测
主动决策检测
置信度标注与透明度
优雅降级与安全边界
完成响应以Markdown格式返回,包含任务状态(成功/失败)、解析摘要和具体输出数据。失败时返回错误码和错误信息,便于定位问题。- 验证返回数据的完整性和格式正确性
详细的输入输出格式请参考下方章节说明。
如果 ~/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 # 推翻的决策日志与教训
在日常交互中自动识别决策信号:
当用户面临权衡选择时:
决策做出后,创建决策记录到 decisions/YYYY-MM-DD-slug.md。在以下时机触发回顾:
回顾日志格式:
DECISION: [决策内容]
CONTEXT: [类型/领域,风险级别]
FRAMEWORK USED: [使用的分析框架]
OUTCOME: [实际结果]
QUALITY: [流程评级: 合理/有缺陷/未知]
LESSON: [下次改进点]
BIASES DETECTED: [沉没成本/锚定/确认偏差等,或无]
用户可随时查询决策统计信息:
| 错误类型 | 原因 | 处理方式 |
|---|---|---|
| 决策记忆目录不存在 | 首次使用未初始化 | 运行初始化命令创建 ~/decision-making/ 目录结构与文件 |
| memory.md超过100行限制 | HOT层积累过多条目 | 将低频访问的条目降级到WARM层(domains/或types/),保持HOT层精简 |
| 框架与决策不匹配 | 选择了不适合当前决策类型的框架 | 先通过澄清问题理解决策上下文,再选择优选匹配框架 |
| 从单一决策推断风险偏好 | 单个数据点不代表模式 | 等待3次一致信号后才将模式提升到HOT层 |
| 上下文限制命中 | 加载了过多WARM层文件 | 降级为仅加载HOT层,按需加载领域或类型文件,告知用户已加载内容 |
| 决策回顾缺失 | 重大决策后未触发回顾 | 30天后通过心跳提示触发回顾,或用户明确要求时触发 |
| 偏好被显式推翻 | 用户改变了之前表达的偏好 | 归档旧偏好,在reversals.md记录推翻日志,更新对应层级文件 |
| 领域与类型模式矛盾 | domains/与types/中的模式冲突 | 领域特定偏好优先(格式),最近信号优先(同级别),不确定时询问用户 |
输入: 用户说"我正在纠结是先做性能优化还是先做新功能,帮我分析一下"
执行过程:
[加载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.
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/ 目录中。无需凭证,无需额外二进制依赖.
A: 自主决策代理通过其混合命名空间(领域x类型双维度)来处理复杂的多因素决策问题。它会根据决策的领域和类型,从相应的领域和类型文件中提取信息,结合用户的风险偏好和框架偏好,应用决策矩阵等工具,进行结构化分析,从而提供全面且深入的决策支持。
A: 如果遇到不熟悉的领域或类型,系统会自动加载相应的领域或类型文件,并尝试匹配最合适的决策框架。如果系统无法确定优选框架,它会提示用户,并建议用户提供更多信息或进行进一步的澄清。
A: 自主决策代理通过置信度标注和透明度机制确保决策的透明度和可信度。每次决策分析都会包含置信度标签(高、中、低),并明确引用框架来源和历史模式。此外,所有假设都会明确陈述,确保用户了解决策背后的逻辑和限制。
A: 自主决策代理通过决策回顾和认知偏差检测来处理认知偏差。它会定期回顾决策,评估流程、结果和认知偏差,如沉没成本、锚定效应等,并提供改进建议,帮助用户避免或减少认知偏差的影响。
A: 自主决策代理通过分层记忆体系和信号学习机制来避免误判或遗漏重要信息。信号观察3次后自动提升为HOT层模式,确保重要信号被充分学习。同时,系统会忽略假设性场景、一次性约束和第三方偏好等非决策性信号,确保决策信号的准确性和相关性。
| 依赖项 | 类型 | 是否必需 | 获取方式 |
|---|---|---|---|
| LLM API | API | 必需 | 由Agent内置LLM提供 |
需要配置对应API Key,详见上文环境配置章节
API Key配置方式:
export API_KEY="${API_KEY:?请设置环境变量}"
配置后需重启会话或开启新终端生效。API Key应妥善保管,避免泄露到版本控制系统.
~/decision-making/ 目录中,不跨设备同步。更换设备或清理文件系统会导致决策记忆丢失,需手动迁移 ~/decision-making/ 目录.Q1:如何知道我的决策偏好被正确学习?
A1:通过查看 memory.md 文件中的内容,你可以看到系统记录的风险偏好和框架偏好。如果这些信号与你的实际决策一致,说明偏好被正确学习。
Q2:系统如何处理我的隐私数据? A2:系统不存储任何个人敏感信息,所有数据都存储在本地,且不进行网络传输。系统遵循严格的隐私保护原则,确保用户数据安全。
Q3:如何更新或删除我的决策偏好?
A3:你可以通过命令行工具或API调用,手动更新或删除 memory.md 文件中的内容,以更新或删除你的决策偏好。
Q4:系统如何处理紧急情况下的决策? A4:在紧急情况下,系统会优先加载HOT层(memory.md)中的关键规则,以提供快速决策支持。如果HOT层中没有相关规则,系统会提示用户进行手动决策。
Q5:系统如何处理跨领域的决策? A5:系统通过混合命名空间(领域x类型双维度)来处理跨领域的决策。它会根据决策的领域和类型,从相应的领域和类型文件中提取信息,以提供全面的分析。
| 错误现象 | 可能原因 | 诊断步骤 | 解决方案 |
|---|---|---|---|
| 决策记忆目录不存在 | 首次使用未初始化 | 检查 ~/decision-making/ 目录是否存在 | 运行初始化命令创建目录结构与文件 |
| memory.md超过100行限制 | HOT层积累过多条目 | 检查 memory.md 文件行数 | 将低频访问的条目降级到WARM层 |
| 框架与决策不匹配 | 选择了不适合的框架 | 检查决策的领域和类型 | 选择合适的框架进行结构化分析 |
| 从单一决策推断风险偏好 | 单个数据点不代表模式 | 检查是否有多次一致信号 | 等待3次一致信号后才提升为HOT层 |
| 上下文限制命中 | 加载了过多WARM层文件 | 检查已加载的文件 | 降级为仅加载HOT层,按需加载领域或类型文件 |
| 风险项 | 等级 | 防护措施 | 验证方法 |
|---|---|---|---|
| 第三方敏感信息泄露 | 高 | 永不存储第三方敏感信息 | 定期审计存储数据 |
| 风险偏好推断错误 | 中 | 不从沉默中推断风险偏好 | 用户反馈验证 |
| 最终决策替代 | 高 | 永不做最终决策 | 用户决策验证 |
| 外部系统访问 | 高 | 不访问日历、邮件或外部系统 | 系统配置检查 |
| 本地文件系统安全 | 中 | 限制对 ~/decision-making/ 目录的访问 | 文件系统权限设置 |
| 场景 | 效率提升量化分析 |
|---|---|
| 产品决策 | 减少决策时间20%,提高决策质量15% |
| 技术架构决策 | 减少决策时间30%,提高决策质量25% |
| 商业战略决策 | 减少决策时间25%,提高决策质量20% |
| 个人生活决策 | 减少决策时间15%,提高决策质量10% |
| 对比项 | 自主决策代理 | 传统决策方法 |
|---|---|---|
| 决策速度 | 快速 | 慢 |
| 决策质量 | 高 | 中 |
| 决策透明度 | 高 | 低 |
| 决策一致性 | 高 | 低 |
| 决策可追溯性 | 高 | 低 |
| 操作场景 | 手动耗时 | 自动化耗时 | 效率提升 |
|---|---|---|---|
| 文件解析与提取 | 5-10分钟/个 | <5秒/个 | 60-120x |
| 批量文件处理(100个) | 8-16小时 | <5分钟 | 96-192x |
| API调用与响应解析 | 2-3分钟/次 | <1秒/次 | 120-180x |
| 多接口数据聚合 | 15-30分钟 | <10秒 | 90-180x |
| 命令执行与结果收集 | 3-5分钟/次 | <2秒/次 | 90-150x |
| 重复任务批量执行 | 因任务而异 | 线性缩减 | 5-50x |
| 错误排查与修复 | 10-30分钟 | <30秒 | 20-60x |
| 对比维度 | 自主决策代理 | 传统手动方式 | 通用脚本工具 |
|---|---|---|---|
| 自动化程度 | 全流程自动 | 完全手动 | 部分自动 |
| 错误处理 | 内置错误恢复 | 依赖人工经验 | 基本try-catch |
| 可复用性 | 参数化配置 | 一次性脚本 | 模板化 |
| 安全合规 | 内置安全检查 | 无安全保障 | 无安全保障 |
| 适用场景 | 具备自改进记忆的结构化 | 通用场景 | 通用场景 |
针对自主决策代理使用中可能遇到的常见问题,提供以下排查方案:
| 错误类型 | 原因分析 | 解决方案 |
|---|---|---|
| API认证失败(401) | API密钥错误或过期 | 检查密钥配置,重新生成token |
| 接口限流(429) | 请求频率超出限制 | 降低调用频率,启用重试退避策略 |
| 响应超时(504) | 网络延迟或服务端负载过高 | 增加超时阈值,检查网络连接 |
| 文件不存在 | 路径错误或文件未创建 | 检查路径拼写,确认文件已生成 |
| 文件格式不支持 | 扩展名不在支持列表中 | 转换为支持的格式后重试 |
| 权限不足 | 当前用户无读写权限 | 检查文件权限,以管理员身份运行 |
| 命令执行失败 | 参数错误或环境依赖缺失 | 检查命令语法,确认依赖已安装 |
| 进程超时 | 命令执行时间过长 | 增加超时设置,优化命令参数 |
| 网络连接失败 | DNS解析失败或防火墙拦截 | 检查网络配置,确认代理设置 |