扩展与生态

扩展与生态

选 Agent、接 Skills、按自己的参数升级三层与看板——让 YMOS 越来越像你自己的系统。

Agent 能力自检

YMOS 不要求特定 Agent 品牌。最低能力只有两项：能读写本地文件、能运行 Python 脚本。第一次把 YMOS 交给某个 Agent 时，让它明确回答：

能力要检查什么缺失后的影响
本地文件能否递归读取 YMOS、写入指定目录、保留中文路径无法稳定读取 SOP 或写回报告
Python能否运行 Eyes/scripts/*.py 与 Console/server.py数据获取和 Console 无法完整运行
Web 搜索能否访问最新公告、财报和新闻，并保留来源深研只能依赖用户提供材料与现有数据源
Skills / 工具能否安装和调用外部 Skill，能否管理 Secret问财等可选能力需要改为手动调用或停用
定时任务能否固定工作目录、时区和依赖顺序日常投研链只能由 Human 手动触发
长期记忆会话结束后是否还能读取同一状态必须更严格地把结论写回 Markdown 真相源
多角色 / subagent能否把有边界的任务分给不同执行体不支持也不阻塞，主控按顺序扮演角色即可
ℹ️ 说明

缺一项不代表不能用。关键是明确降级，不要让 Agent 假装已经搜索、安装、写回或执行。

统筹一个，执行可以多个

可以把 Agent 工具分成两个角色，避免和 YMOS 的「操盘层」混淆：

角色怎么选作者当前用法
运行统筹负责长期记忆、任务协调、定时任务与状态连续性，建议只选一个当前使用 Hermes 统筹 YMOS；OpenClaw 同样支持完整主链与调度
任务执行工具按一次深研、一次改造、一个脚本或一条调度任务临时调用，可以多个并存Claude Code、Codex、OpenClaw 等按任务分担，产出统一写回 YMOS

为什么统筹建议只有一个：两套框架各自保存一半记忆，会形成两个互相不知道对方存在的「当前状态」。任务执行工具可以换，因为真相源不是对话记录，而是磁盘上的 Profile、状态机、报告和事件流。

💡 提示

只使用 OpenClaw、Claude Code、Codex 或其他单一 Agent 也能完整跑 YMOS；没有常驻统筹时，要更主动地维护 Profile、BrainStorm 和状态机，不能把关键决定只留在聊天窗口。

系统级扩展：先准备一份个人参数包

V4 提供的是作者打样，不是一套要求用户照抄的成品。真正的系统级升级，是先把你的参数说清，再分别投影到三层。不需要一次写满，但至少把已知与未知分开：

MARKDOWN
市场与时区：
主要标的 / 明确不做：
研究频率与可投入时间：
持有周期与资金期限：
主要策略结构：
入场依据：
失效信号：
仓位与损失预算：
已知行为弱点：
希望自动化的重复劳动：
希望 Human 必须确认的节点：
Reader 想看什么：
操盘台想怎么排字段和提醒：
尚未想清、必须留空的参数：

来源优先级：Human 明确确认的 Profile → 实际计划与成交记录 → 旧日志 / BrainStorm → 作者示例。作者示例只能帮助提问，不能替用户填空。

参数怎样投影到三层

你的参数主要修改哪层常见文件验收问题
市场、时区、信息范围、数据预算投研层.env、Eyes SOP、数据脚本、定时任务能否按需要看到事实，失败时是否降级
能力圈、策略族、入场、认错、期限、风险预算策略内核层Strategy Profile、P 系列、策略 SOP同一事实是否按你的裁判得出一致判断
行为弱点、操作顺序、Human 确认点操盘层rules.json、计划/决策 SOP、事件契约最容易变形的那一步是否被提前拦住
阅读偏好、字段顺序、布局、提醒方式Reader / Console 看板config.json、三个 HTML是否更容易看懂和操作，且没有创造第二套策略

Reader 是投研内容的阅读界面；交易计划台和买卖决策台是操盘层的可视界面。它们不是独立的第四层，页面字段也不能反过来定义策略。

让 Agent 帮你改 YMOS

用户不需要先学会写代码，但要能说清希望系统哪里变得更像自己。可以把这段发给 Agent：

MARKDOWN
先完整读取 YMOS/AGENT_GUIDE.md、YMOS/进阶指南.md、ARCHITECTURE.md，
以及与本次需求有关的 Profile、SOP 和 Console 文档。

我要解决：<实际问题>。
我的市场、周期和使用习惯：<参数>。

请先判断应修改投研层、策略内核层、操盘层，
还是只修改 Reader / Console 的显示；列出真相源和受影响的上下游，
再给最小改造方案。保留 Human in the Loop、失败降级、事件只追加；
真实 Key 只放 .env。修改后做正常、空结果、失败三个测试，不要直接发布或 push。

Agent 应先给出「改哪层、为什么、哪些文件受影响」，再动文件。只说「帮我优化 YMOS」通常会造成跨层大改和新的冲突。

系统扩展的标准落地链

MARKDOWN
脚本 / API / Skill     提供原子能力与外部手脚
        ↓
SOP                    定义何时调用、输入输出和失败降级
        ↓
Agent 角色             约束谁能读、谁能写、依赖顺序
        ↓
Profile / 状态机       保存当前规则与事实真相
        ↓
Reader / Console       负责阅读、计划、门禁和留痕
        ↓
BrainStorm / 审计      让问题与结果回到下一轮改造

新增一个系统级能力时，按这个清单落地：

  1. 明确属于哪一层，解决什么真实问题
  2. 说明输入、输出、来源时间和失败降级
  3. 更新 .env.example 或配置样例，但不提交真实配置
  4. 接入 SOP 与 Agent 读写边界
  5. 需要显示时再改 Reader / Console
  6. 用正常、空结果、失败、路径越界做最小测试
  7. 更新 README / 进阶指南 / CHANGELOG 中真正受影响的部分
❗ 重要

扩展时记住这句：脚本提供原子能力，Skill 提供手脚，SOP 负责编排，Agent 定义角色边界，Profile 与状态机保存真相，前端只做投影。

发布自己的扩展

  • 不提交 API Key、账户、持仓或个人运行记录
  • 不把个人参数写成公共默认；参考 Profile 必须标 disabled_by_default
  • 提供输入、输出、失败降级和最小测试
  • 明确属于投研层、策略内核层还是操盘层，并说明删掉它会影响什么

欢迎贡献的方向：新的数据驱动、不带参数推荐的策略结构卡、Profile Schema 改进、跨市场的结构矛盾案例、Console 与状态机的契约测试。

改造完之后：验收清单

  • 每个新增模块的三层归属明确
  • Profile 里没有系统偷偷补的数值
  • 混合策略写明了裁判冲突时谁优先
  • 驱动失败会明确降级，不静默吞掉
  • 计划与盘中执行是分离的；单笔交易事件只追加，历史改不掉
  • Agent 不代写真实执行证据
  • 每个内核修改都有反证、审批和回滚
  • Agent 的统筹、执行与写回真相源没有分裂
  • Reader / Console 只投影规则，没有形成第二套策略
  • 删掉所有可选模块后，最小闭环仍然能跑