一、微信文章内容解读：OpenClaw 高级用法与生产级 Agent 架构

文章的核心观点是：AI Agent 的真实难点不在“会不会回答”，而在于上下文工程、工具编排与成本控制。

核心结论包括：1. Agent 与普通聊天模型不同，它会经历“思考 → 行动 → 观察 → 再思考”的循环。2. 成本爆炸的主要原因不是用户输入，而是每轮都重复携带系统提示、工具定义、历史对话、记忆与状态，导致上下文膨胀。3. 真正的生产级能力不是一句 Prompt，而是 Context Engineering：如何压缩上下文、做缓存、分层模型、控制多轮调用成本。4. OpenClaw 一类系统的价值，在于把工具、状态、日志、自省、长期运行等能力组合成可执行的 Agent Runtime。

二、如何在本机实现文章中提到的架构

在本机实现类似架构时，可将系统拆成七层：

1. 模型层：负责推理与规划，可使用云模型 API 或本地模型。2. Agent 调度层：负责接收目标、组织上下文、决定是否调用工具并循环执行。3. Skills / 工具层：文件、命令、编程、网络、办公等可调用能力，每个工具都可用 SKILL.md 描述。4. 记忆 / 上下文层：拆分为短期记忆、工作记忆、长期记忆，并通过摘要、检索、裁剪控制成本。5. 状态层：保存 session、步骤、产物、错误、时间等，可用 SQLite + 本地文件系统实现。6. 安全层：命令白名单、目录白名单、高危操作人工确认、技能分级。7. 可观测层：模型调用日志、工具调用日志、任务步骤日志、失败原因分析。

最关键的实现原则：- 不是所有内容都回灌给模型，只传递当前任务真正需要的上下文。- 工具输出必须摘要化，避免大段原始日志回流。- 所有危险操作必须受控，所有执行都要留痕。

三、明确目标：OpenClaw 读取 Obsidian 会议记录，再交给 Claude Code / Codex 生产代码

用户进一步澄清后，目标从“通用架构”收敛为一条实际可执行的链路：

Obsidian 会议记录→ OpenClaw 检索与提炼→ 生成开发规格（task-spec.md）→ 写入代码仓库→ 调用 Claude Code 或 Codex→ 在仓库中生成或修改代码→ 将结果写回 Obsidian

这一链路的关键不是“直接把会议纪要发给编码 Agent”，而是先做结构化转换：- 从会议记录中提取背景、已确认决策、范围、验收标准、待确认项- 产出适合编码代理消费的 spec 文档- 再由 Claude Code / Codex 在代码仓库上下文中执行实现工作

角色分工被定义为：- Obsidian：知识库- OpenClaw：项目秘书 / 总控 Agent- Claude Code / Codex：程序员

四、推荐的整体工作流

推荐的工作流如下：

1. OpenClaw 从 Obsidian Vault 中搜索与主题相关的会议记录。2. OpenClaw 将多篇会议记录整理为 task-spec.md、decisions.md、open-questions.md。3. OpenClaw 将这些文件写入代码仓库中的 docs/ai-context/。4. OpenClaw 调用 Claude Code 或 Codex，在当前仓库目录下依据 spec 改代码、跑构建、跑测试。5. OpenClaw 收集执行结果，并回写到 Obsidian 的 AI-Delivery 区域。

这样做的优势：- 降低噪声：避免把原始会议讨论直接喂给编码代理。- 增强稳定性：Spec 文档更适合工具消费。- 便于追踪：代码与知识库之间形成闭环。- 易于扩展：后续可接 Git、CI/CD、IIS 发布等工程步骤。

五、Windows 本机技能（Skills）设计思路

围绕这条链路，设计了一组技能目录：

skills/  obsidian_search/  obsidian_to_spec/  repo_context_writer/  run_codex/  run_claude_code/

每个 Skill 建议至少包含：- SKILL.md：说明用途、参数、输出、适用场景与限制- run.ps1：实际执行的 PowerShell 脚本

示例能力包括：1. obsidian_search：按 topic 在 Vault 中搜索会议记录。2. obsidian_to_spec：读取多篇 Markdown 会议纪要，整理出开发规格。3. repo_context_writer：将规格文件写入仓库 docs/ai-context/。4. run_codex：在指定 repo 目录执行 codex 命令并读取 task-spec.md。5. run_claude_code：在指定 repo 目录执行 claude 命令，并遵循 CLAUDE.md 中的长期项目规则。

六、示例脚本与项目约定

在前面的设计中，给出了一套 PowerShell 技能模板，用于本机落地：

1. 搜索会议记录：- 在 Obsidian Vault 下递归查找 Markdown 文件- 用关键词匹配内容- 输出匹配文件路径

2. 生成 task-spec.md：- 先拼接原始会议内容- 后续可再由大模型整理为结构化规格- 目标文件写入临时目录或 workspace

3. 写入仓库上下文：- 创建 docs/ai-context/- 写入 task-spec.md- 预留 decisions.md 与 open-questions.md

4. 调用 Claude Code / Codex：- 在项目目录下启动命令行代理- 让其优先读取 docs/ai-context/task-spec.md- 强制先分析，再实现，再构建与测试，再总结

5. 构建、测试与回写：- 可通过 dotnet restore / build / test 验证修改- 最终通过 writeback 技能将结果写入 Obsidian

七、生产化升级方案：OpenClaw + Obsidian + Claude Code/Codex + Git + CI/CD

在进一步的讨论中，方案被提升为更接近生产可用的流水线：

Obsidian Vault→ OpenClaw Orchestrator→ Project Repo→ Git→ CI/CD→ 发布 / 健康检查→ OpenClaw 回写 Obsidian

这一阶段明确了四个阶段：

Phase 1：知识整理- 读会议记录- 生成 task-spec.md、decisions.md、open-questions.md

Phase 2：代码实现- Claude Code 或 Codex 读取 spec 与仓库- 在既有模块和规则下实施变更

Phase 3：工程化落地- Git 分支创建- Build / Test- Publish / 部署脚本- 健康检查

Phase 4：知识回写- 本次完成项- 修改文件摘要- 构建结果- 待确认项- 风险

这一步确立了完整的“知识流 → 规格流 → 代码流 → 交付流”。

八、推荐的目录与文件规划

推荐的目录布局如下。

Obsidian：D:\ObsidianVault\  Meetings\  Decisions\  AI-Delivery\

代码仓库：D:\Projects\AuthCenter\  docs\ai-context\  CLAUDE.md

OpenClaw Skills：skills/  obsidian_search/  obsidian_to_spec/  repo_context_writer/  run_claude_code/  run_codex/  git_ops/  ci_trigger/  writeback_obsidian/

其中：- Meetings 用于沉淀原始会议记录- Decisions 用于记录长期决定- AI-Delivery 用于记录 AI 执行结果- docs/ai-context/ 用于给编码代理提供当前任务上下文- CLAUDE.md 用于维护项目长期规范，如技术栈、目录规则、禁忌、测试要求等

九、示例文件：task-spec.md 与 CLAUDE.md 的定位

在对话中，task-spec.md 被定义为“给编码代理看的主文件”，通常包含：

- Background- Confirmed Decisions- Scope For This Iteration- Acceptance Criteria- Constraints- Open Questions

而 CLAUDE.md 被定义为“项目长期规则文件”，典型内容包括：- 技术栈：.NET、ABP vNext、xUnit- 代码规范：遵循现有模块结构、重要领域逻辑需加测试- 禁止事项：不能破坏现有公开 API、数据库结构变更必须带 migration- 固定工作流：先读 spec，再写计划，再实施，再构建测试，再输出总结

这种划分可以让：- 本次任务上下文进入 docs/ai-context/- 长期项目约束固化在仓库根目录- 编码代理既知道“这次做什么”，又知道“长期该怎么做”

十、Windows 本机完整项目骨架（非 .NET Orchestrator 版本）

在此之前，已给出一套纯目录与脚本层面的 Windows 本机骨架，主要包括三部分：

根目录：D:\AIFlow\  openclaw\  repos\  obsidian\

openclaw/config/settings.json 中定义：- vaultPath- repoPath- workspacePath- logPath- allowedCommands- allowedWriteRoots

同时给出了八个可落地 Skill：1. obsidian_search2. obsidian_to_spec3. repo_context_writer4. git_create_branch5. run_claude_code6. run_codex7. build_dotnet8. writeback_obsidian

这一版的重点不在服务化，而在于先用：- 目录约束- SKILL.md- PowerShell 脚本把完整链路跑通。

十一、建议的最小人工操作流程

为了降低复杂度，建议先采用半自动模式，按顺序执行：

1. 在 Obsidian 中记录会议纪要。2. 用 obsidian_search 搜索目标主题会议记录。3. 用 obsidian_to_spec 生成 task-spec.md。4. 用 repo_context_writer 写入仓库 docs/ai-context/。5. 用 git_create_branch 创建功能分支。6. 用 run_claude_code 或 run_codex 调起编码代理。7. 用 build_dotnet 执行构建与测试。8. 用 writeback_obsidian 回写实现结果到 Obsidian。

只要这 8 步跑通，就已经具备一个可用的本机 AI 开发闭环。

十二、首次测试案例

对话中还设计了一个可直接用于验证的会议记录样本，主题为“统一认证中心”。

样例包含：- 背景：多个子系统各自维护用户和权限，造成重复管理- 已确认决策：使用 .NET + ABP vNext，先做统一用户、组织、角色基础模块，数据权限先按组织授权- 待办事项：组织树、统一用户实体、角色权限分配、预留数据范围授权- 验收标准：可新增组织、用户、分配角色，并按组织限制数据访问- 待确认问题：是否一期接 OIDC，历史账号是否自动迁移

建议将这份会议纪要写入 Obsidian 的 Meetings 目录，然后跑完整条链路，验证：- 是否能检索到会议记录- 是否能生成 task-spec.md- 是否能写入 repo- 是否能启动 Claude Code / Codex 并开始工作

十三、核心理念总结

本次对话中反复强调的核心理念可以归纳为：

1. 不要把会议纪要原样丢给编码代理。要先整理成开发规格，减少噪声与歧义。

2. OpenClaw 更适合做总控，不适合直接承担全部编码职责。它更像项目经理、秘书或工作流编排器。

3. Claude Code / Codex 更适合做仓库内编码与修复。它们应该在当前 repo 上下文中工作，而不是在原始会议文本上工作。

4. 真正的生产能力来自闭环。会议纪要→ 规格 → 代码 → 构建 → 发布 → 结果回写

5. 安全边界和日志留痕必须从第一天开始做。至少要有命令白名单、路径白名单、高危确认和步骤日志。

十四、推荐实施顺序

综合整段对话，最推荐的实施顺序是：

第一阶段- 建好目录- 写好 4 个关键技能：obsidian_search、obsidian_to_spec、repo_context_writer、run_claude_code

第二阶段- 接入 git_create_branch、build_dotnet、writeback_obsidian

第三阶段- 增加 decisions 提取器、open questions 提取器- 强化 spec 结构化质量- 增加 git commit 能力

第四阶段- 接入测试环境发布- 接入 IIS 部署与健康检查- 再考虑更强的自动化和服务化