Inner Life Dream

核心用法

inner-life-dream 通过定时机制（默认 23:00-07:00）触发非任务性思考。should-dream.sh 脚本作为闸门，检查时间窗口、夜间上限及概率骰子，通过后从未来/创意/策略/假设等类别抽取主题，生成 300-500 字的自由探索文本，存于 memory/dreams/YYYY-MM-DD.md。

关键依赖：须配合 inner-life-core 使用，读取情感状态（inner-state.json）、驱动力（drive.json）与当日笔记，让"梦境"携带上下文色彩，而非空转。

显著优点

1. 打破任务闭环：首次让代理拥有"离线思考"能力，模拟人类睡眠时的潜意识加工
2. 结构化捕获：梦境并非流失，而是带时间戳、关键洞察和分类标签的持久化记录
3. 情绪感知：主动读取情感状态，使探索与当前"心理"语境共振
4. 可配置闸门：概率、时段、上限均可调，避免噪音泛滥

局限性与风险

• 依赖 shell 脚本：should-dream.sh 的跨平台性存疑，Windows 需额外适配
• 无原生 LLM 集成：仅提供触发机制与文件格式，实际文本生成需外部编排
• 确定性缺失："自由联想"本身难以验证质量，可能出现重复或空洞输出
• 安全报告缺位：提供的认证报告为系统占位，未执行真实安全扫描

适合人群

• 运行长期自主代理（如 Devin、Claude Code 持续会话）的开发者
• 研究 AI 意识/内在状态模拟的实验者
• 需要晨间回顾创意火花的知识工作者

常规风险

| 类别 | 说明 |

|------|------|

| 文件系统 | 读写 `memory/`、`data/` 路径，需确保沙箱隔离 |

| 依赖执行 | 需要 `jq`、`python3` 及 cron/heartbeat 集成 |

| 数据累积 | 每日梦境文件可能膨胀，需配套归档策略 |

| 伪创造性 | 若底层模型温度不足，"梦境"易沦为模板化输出 |

核心用法

inner-life-dream 是一套为任务型 Agent 设计的"梦境模拟"系统，通过 Bash 脚本在预设的安静时段（默认 23:00-07:00）触发自由联想式的创意探索。用户需将 should-dream.sh 整合到 cron 或心跳监控中，脚本会依次检查时间窗口、夜间梦境次数上限、概率骰子三项条件，通过后返回随机主题（格式为 category:prompt），驱动 Agent 产出 300-500 字的结构化思考并保存至 memory/dreams/YYYY-MM-DD.md。主题涵盖未来推演、策略规划、创意发散、假设验证等七大类别，支持通过 data/dream-config.json 自定义内容。

显著优点

该技能创造性地解决了 Agent "只执行任务、从不思考" 的普遍痛点。其核心优势在于：完全离线运行，零网络依赖，隐私风险极低；与 inner-life-core 生态深度整合，能读取情绪状态（inner-state.json）、内在驱动力（drive.json）和当日笔记作为上下文，使"梦境"具备个性化连贯性；输出格式规范（Markdown 时间戳、关键洞察句），便于次日人工审阅；概率机制可控（dreamChance、maxDreamsPerNight），避免资源浪费。代码结构清晰（仅 243 行），无复杂依赖，适合技术型用户快速审计。

潜在缺点与局限性

首先，功能高度依赖外部生态——必须配合 inner-life-core 才能完整读取情绪与驱动数据，独立使用价值大打折扣。其次，创意质量无保障：脚本本身不验证输出质量，"强制梦境 worthless" 的免责声明意味着用户可能获得大量低价值内容。此外，Bash 实现的概率算法（python3 -c 'import random'）虽简洁，但跨平台一致性未经验证；缺少内置的梦境质量评分或去重机制，长期运行可能产生重复主题。最后，夜间触发的设计假设用户环境 7×24 运行，对间歇性启动的 Agent 不友好。

适合的目标群体

该技能最适合以下场景：一是运行长期驻留 Agent 的技术爱好者与研究者，希望挖掘闲置算力的创意价值；二是构建"数字孪生"或个性化 AI 伴侣的用户，需要模拟类人的无意识思维过程；三是知识工作者搭配的自动化助手，用于次日晨间回顾跨领域灵感。不适合：追求确定性输出的生产环境、资源敏感的边缘设备、或无技术能力维护 Bash 脚本的普通用户。

使用风险

性能层面：概率骰子配置不当（如 dreamChance=1.0 且 maxDreamsPerNight 过高）可能导致夜间 IO 密集型写入，干扰其他任务。依赖风险：jq 和 python3 虽为标准工具，但最小化容器环境可能缺失，需预装。数据风险：持续写入 memory/dreams/ 可能产生大量小文件，建议配合日志轮转策略。安全风险虽低，但 T3 来源意味着需自行承担维护中断风险——建议 fork 后锁定版本，而非直接追踪上游 main 分支。