这次分享沿着一条真实演进线展开：当 Agent 进入日常工作后，它会从能用、能修、能委派，走到能排查真实问题、沉淀经验，最后反哺 OpenClaw 社区。
我最早只是把 OpenClaw 当工具用：做巡检、查问题、跑脚本。用久了才发现，Agent 进入日常工作后，问题会从“回答质量”扩展到运行、执行、工具和经验沉淀。
内存、磁盘、OOM、Gateway、配置都可能让 Agent 突然不可用。
主 agent 被写操作和试错过程占住；简单任务也不该一直烧强模型，需要按任务复杂度分层用模。
容器和 Kubernetes 问题不能靠猜，CP Agent 需要发现工具、调用只读能力并收集证据。
修复、委派和排障如果只留在 session 里，下次还是从零开始。
IronClaw 修复能力通过 LiClaw 入口默认提供：每天修复超过 10 个沙箱异常，约节约半个人力处理日常环境问题，AI 修复覆盖复杂环境异常。
IronClaw 把沙箱当成需要被托管的 Agent 运行环境：常驻监控内存、磁盘、Gateway、OOM 和配置状态。
确定性问题先走 Doctor 诊断和备份还原；复杂异常再进入受控 AI 修复，通过时长、工具调用次数、尝试次数和并发锁控制成本。
OctoClaw 建在 OpenClaw 之上，探索快速响应、按需委派、子 agent 隔离、IM 状态回传和成本路由。它的意义不是“写了一个插件”，而是把委派边界、状态权威和反馈回路工程化。
用 AGENTS.md 和 Skills 约束主 agent，验证先回复、再委派、按任务分层用模的方向。
补 workflow、artifact、状态和结果规则，把交付物和回传格式从 prompt 约定变成工程合同。
OpenClaw TaskFlow 管生命周期；OctoClaw 管 policy、WorkContract、ledger、IM surface 和 Auto Router。
我现在的理解：多 Agent 选型第一问不是“要拆几个”，而是任务之间是否共享同一段上下文。边界清楚才适合拆出去，必须共享状态才考虑 Agent Team。
边界清楚的任务交出去，限定模型、工具、范围、产出和回传，解决隔离、压缩和并行。
必须共享状态、角色持续互相影响时再启用，需要通信协议、状态层和仲裁机制。
工作单元多、验证成本高时，把 fan-out、循环验证和 review 写成可审查脚本。
便宜模型负责大部分执行，强模型只在复杂规划、卡住、风险判断和最终 review 点介入。
开发 OctoClaw 的过程也改变了我的 AI 编程方式：Codex 负责设计、拆包和验收；
opencode-supervisor 通过 ACP/tmux 指挥 OpenCode + GLM 执行，完成后再回到 Codex review 和端到端验证。
GPT-5.x 澄清需求、拆方案、定边界、写 work packet；
使用 superpowers 做 brainstorming / writing-plans；
opencode-supervisor 固化发送、轮询、fixback 和验收门禁。
通过 ACP/tmux 驱动 OpenCode Worker，用 GLM 按 work packet 实现；
OMO 的 ultrawork 模式只作为局部加速器。
OpenSpec 定变更边界，BDD 定行为验收；
TDD 是执行纪律，关键行为先红后绿。
实现和验证分家；
Codex review diff，E2E 像用户一样跑入口、委派、状态和回传，避免只证明代码“看起来对”。
在 OctoClaw 实践中发现 OpenClaw 子 agent 和 Slack 线程问题，提交 PR 并成为 OpenClaw contributor。两个 PR 已经被 OpenClaw 官方合入。
sre-autopilot 把一次排障拆成 DB、CP、NW、APP 四个方向并行查证。CP 方向已经实现了排障 Agent：既可以独立承接自然语言问题，也可以作为外部 Agent 的受控工具能力；LLM 负责理解和规划，工具循环负责查证，工程边界负责把范围、权限、轮次和证据收住。
排障不是单点问答，而是 DB、CP、NW、APP 同时收集证据，最后合并判断。
CP 方向围绕 Pod、Node、事件、日志和指标展开，先确定范围，再把事实链收集完整。
它可以作为 CP Agent 直接回答自然语言问题，也可以被 OpenClaw / Claude Code / OpenCode 等外部 Agent 调用。
实现 CP Agent 后，我对 Agent 的理解从“LLM 聊天”变成了：会规划、会查证、被约束、能交付证据。
PraxisBase / 知行基座放在最后讲，因为它是收束：个人版已 GA，团队版开发中。它要解决的不是一次任务怎么跑，而是把个人与团队 agent 的经验变成可审核、可压缩、可复用的长期资产。
Native Memory Bridge 负责接入、脱敏、保留 source ref / hash，并生成提案候选。
参考腾讯文章：Harness 是载体，知识沉淀才是护城河；稳定知识必须审核晋升。
AgentMemory / GBrain 提供 session 记忆、检索、偏好和经验召回能力。
借鉴 SkillClaw 的 skill 复用思路，将 episode 提炼为 known fix、procedure 和 SKILL.md。
如果前面讲的是 Agent 工程化、托管和上游贡献，这里补充另一条线：AI coding 进入硬件、内容生产、开源协作和亲子创造，把“想法到作品”的距离压短。
第一个作品不是纯软件页面，而是 AI coding 帮我把天气 UI、数据接口、硬件展示和内容传播串起来。
AI 日报由 OpenClaw 定时任务驱动，把海外数据源、微信公众号、GitHub 热门、模型筛选、人工口径 review、中文终稿和 TTS 投递接成一条流水线。
每天 7:00 生成预览和审核稿，通过 preview/state 固定当天口径。
海外源、技术博客、GitHub 热门和公众号统一进入模型打分、过滤和去重。
同源生成文字日报和 TTS 音频，通过 OpenClaw message 一次投递。
OmniRoute API Proxy 验证了 Codex 套餐多人贡献方案，也把真实使用中的缺口补进官方版本。
孩子通过 iPad 上的 ChatGPT 指挥 Mac mini 上的 Codex，从头脑风暴到需求确认，再到 Bug 修复、画面美化和道具增强，两天做出 UI 较好的可玩版本。
先让孩子说清楚想玩什么，再把想法收敛成可实现需求。
第一天先跑通核心玩法，接受画面粗糙和明显 Bug。
围绕 Bug、碰撞、道具、场景和 UI 连续修正。
第二天已经从原型变成孩子愿意继续玩的版本。
