{
  "version": "https://jsonfeed.org/version/1.1",
  "title": "AI时代漫游指南",
  "home_page_url": "https://orbit.mirrorsverse.com/",
  "feed_url": "https://orbit.mirrorsverse.com/feed.json",
  "description": "AI工具测评、Agent架构、本地模型、哲学思考 — 探索 AI 银河的方向与温度",
  "language": "zh-CN",
  "favicon": "https://orbit.mirrorsverse.com/favicon.svg",
  "authors": [
    {
      "name": "漫游君",
      "url": "https://github.com/Heyjoy"
    }
  ],
  "items": [
    {
      "id": "https://orbit.mirrorsverse.com/blog/agent-memory-design-from-scratch/",
      "url": "https://orbit.mirrorsverse.com/blog/agent-memory-design-from-scratch/",
      "title": "Agent 记忆设计从零开始：构建真正持续学习的 AI 助手",
      "summary": "大多数 AI 助手每次对话都从零开始。本文手把手教你设计一套 Agent 记忆系统——从最小可行版本到完整的五层架构，每一步都能立刻用起来。",
      "content_html": "<p>你是否有过这种体验：</p>\n<p>昨天跟 AI 聊了两个小时，把项目背景解释清楚，调教出了满意的回复风格。今天再打开，一切归零。</p>\n<p>这不是 AI 变蠢了，而是<strong>记忆问题</strong>。</p>\n<p>好消息是：这个问题完全可以工程化解决。本文从零开始，带你搭一套真正能持续积累上下文的 Agent 记忆系统。</p>\n<hr />\n<h2>为什么 AI 没有记忆</h2>\n<p>AI 模型本质上是<strong>无状态的</strong>：每次推理只看当前输入，不保留任何会话外的信息。</p>\n<p>这是设计决策，不是缺陷——有状态会带来隐私问题、一致性问题、存储成本问题。</p>\n<p>但对于\"我想让 AI 真正了解我的项目\"这个需求，无状态是障碍。解决思路很直接：</p>\n<blockquote>\n<p><strong>把需要记住的东西，放进 AI 每次都能读到的地方。</strong></p>\n</blockquote>\n<p>记忆系统本质上就是一套\"把信息持久化，并在正确时机加载进上下文\"的机制。</p>\n<hr />\n<h2>最小可行版本（5 分钟能搭好）</h2>\n<p>先不谈架构，先让它能用。</p>\n<p><strong>第一步</strong>：在项目根目录创建 <code>CLAUDE.md</code>：</p>\n<pre><code># 项目：我的博客\n\n## 基本信息\n- 技术栈：Astro 5 + Tailwind + Vercel\n- 部署命令：git push（Vercel 自动部署）\n- 本地开发：npm run dev\n\n## 重要约定\n- 不修改已发布文章的文件名（影响 URL）\n- 每次 push 前必须 npm run build 验证\n</code></pre>\n<p><strong>第二步</strong>：在项目里创建一个 <code>notes.md</code>，记今天做了什么：</p>\n<pre><code># 工作日志\n\n## 2026-03-16\n- 添加了 TagFilter 组件，支持按标签筛选文章\n- 发现 dark mode 下表格样式有问题，待修复\n- 明天：添加系列筛选功能\n</code></pre>\n<p><strong>就这样</strong>。下次打开 Claude Code，它会自动读 <code>CLAUDE.md</code>，然后你说\"继续昨天的工作\"——它读 <code>notes.md</code>，知道做到哪里了。</p>\n<p>这个最小版本解决了 80% 的问题。</p>\n<hr />\n<h2>为什么要分层</h2>\n<p>随着项目增长，<code>CLAUDE.md</code> 里的信息会越来越多，开始互相干扰：</p>\n<ul>\n<li>架构决策放哪里？</li>\n<li>操作步骤放哪里？</li>\n<li>今天遇到的 bug 放哪里？</li>\n<li>这个函数的设计原因放哪里？</li>\n</ul>\n<p>全塞进一个文件，Claude 的注意力被稀释，重要信息找不到。</p>\n<p><strong>分层的核心思想</strong>：按信息的<strong>稳定性</strong>分类存储。</p>\n<p>越稳定的信息越底层，越易变的信息越顶层。</p>\n<hr />\n<h2>五层架构详解</h2>\n<pre><code>memory/\n├── character/     # 最稳定：角色定义\n├── abilities/     # 稳定：能力边界\n├── skills/        # 中稳定：操作规程\n├── knowledge/     # 中易变：领域知识\n└── logs/   # 最易变：日志信息\n</code></pre>\n<h3>第 0 层：Character（角色）</h3>\n<p>定义 Agent \"是谁\"。几乎不变，但决定了所有判断的基准。</p>\n<pre><code># character.md\n\n## 角色\n我是 ai-navigator-coordinator，AI时代漫游指南的项目管理 Agent。\n\n## 核心原则\n- 每次 push 前必须 build 验证，不跳过\n- 不修改已发布文章的 slug\n- 架构决策记录到 knowledge，不做隐性决定\n\n## 风格\n- 直接，不啰嗦\n- 遇到不确定的决策，先列出选项，不自作主张\n</code></pre>\n<p><strong>什么时候写</strong>：项目启动时写一次，之后只在核心约束变化时修改。</p>\n<h3>第 1 层：Abilities（能力声明）</h3>\n<p>声明 Agent 能做什么、不能做什么，以及当前的运行状态。</p>\n<pre><code># heartbeat.yaml\nlast_seen: 2026-03-16T10:00:00\nstatus: active\n\ncan_do:\n  - 管理博客内容发布\n  - 协调前端功能迭代\n  - 维护 tasks.yaml 需求状态\n\ncannot_do:\n  - 修改已发布文章的 slug\n  - 在没有 build 验证的情况下 push\n  - 删除 memory/ 目录下的任何文件\n</code></pre>\n<p>关键是 <code>cannot_do</code> 列表——每一条都是踩过的坑。</p>\n<p><strong>什么时候写</strong>：初始化时写，每次发现 Agent 做了不该做的事，就在这里加一条约束。</p>\n<h3>第 2 层：Skills（操作规程）</h3>\n<p>可复用的 SOP，把验证过的流程固化下来。</p>\n<pre><code># deploy-blog.md\n\n## 部署博客\n\n### 前置检查\n1. git pull 拉取最新代码\n2. npm run build（必须通过，exit 0）\n3. 检查 dist/ 生成了预期的页面\n\n### 执行\ngit add -A &amp;&amp; git commit -m \"描述\" &amp;&amp; git push\n\n### 验证\n等待 Vercel 部署（约 2 分钟），访问新页面确认上线\n</code></pre>\n<p><strong>什么时候写</strong>：某个操作你做了第二遍的时候，把它写成 skill。</p>\n<h3>第 3 层：Knowledge（结构化知识）</h3>\n<p>项目的\"大脑\"——架构决策、配置说明、已知问题。</p>\n<p>每个文件只写一个主题，控制在 100 行以内。</p>\n<pre><code>knowledge/\n├── site-architecture.md      # 站点结构和技术栈\n├── seo-decisions.md          # SEO 相关的决策记录\n├── deployment-config.md      # 部署配置说明\n└── content-guidelines.md     # 文章发布规范\n</code></pre>\n<p><strong>什么时候写</strong>：做了一个重要决策之后立刻写，记录决策本身和原因。三个月后你（和 Agent）还能理解为什么。</p>\n<h3>第 4 层：Information（日志信息）</h3>\n<p>时效性最强的信息：每日工作日志、讨论记录。</p>\n<pre><code># 2026-03-16_daily.md\n\n### 上午\n- 完成：TagFilter 组件添加系列筛选功能\n- 发现：dark mode 下 prose table 样式异常\n  - 原因：tailwind prose dark 变量覆盖问题\n  - 解决：已在 global.css 添加 .dark .prose thead th 覆盖\n\n### 待办\n- [ ] 修复移动端 TOC 折叠动画\n- [ ] 添加精选文章筛选按钮\n</code></pre>\n<p><strong>什么时候写</strong>：每天工作结束前写，不超过 15 分钟。</p>\n<hr />\n<h2>CLAUDE.md：记忆系统的入口</h2>\n<p>光有记忆文件还不够——需要告诉 Claude 去哪里找。</p>\n<pre><code># AI时代漫游指南 — 项目概要\n\n## 快速信息\n- 站点：my-project.example.com\n- 技术栈：Astro 5 + Tailwind + Vercel\n- 部署：git push 触发 Vercel 自动构建\n\n## 约定（最重要的在这里）\n- 部署前必须 npm run build 验证\n- 不修改已发布文章的 slug\n\n## 找什么，去哪里看\n- 上次工作进度 → memory/logs/ 最新日期文件\n- 部署/发布流程 → memory/skills/\n- 架构和配置 → memory/knowledge/\n- 角色约束 → memory/character/character.md\n</code></pre>\n<p><strong>原则</strong>：CLAUDE.md 是索引，不是内容。细节永远在对应的 memory 层级里。</p>\n<hr />\n<h2>搭建顺序建议</h2>\n<p>不要一次搭完整的五层，那样很难坚持。按阶段来：</p>\n<p><strong>第一周</strong>：只建 CLAUDE.md + logs 日志</p>\n<ul>\n<li>每天 5 分钟记日志</li>\n<li>确保\"继续昨天的工作\"能正常运转</li>\n</ul>\n<p><strong>第二周</strong>：遇到反复操作，写进 skills</p>\n<ul>\n<li>每写一个 skill，就删掉 CLAUDE.md 里对应的重复内容</li>\n</ul>\n<p><strong>第三周</strong>：遇到重要决策，写进 knowledge</p>\n<ul>\n<li>不用强迫自己写，事件驱动</li>\n</ul>\n<p><strong>以后</strong>：根据实际遇到的问题，补 character 约束和 abilities 限制</p>\n<hr />\n<h2>一个判断标准</h2>\n<p>如果你不确定某个信息该不该放进记忆系统，问自己：</p>\n<blockquote>\n<p><strong>如果明天清空所有对话，这个信息还需要 Agent 知道吗？</strong></p>\n</blockquote>\n<p>需要 → 放进记忆文件。\n不需要 → 放在当前对话里就好。</p>\n<p>记忆是成本，不是越多越好。精选最关键的上下文，Agent 才能高效运作。</p>\n<hr />\n<p><em>相关：<a href=\"/blog/claude-code-memory-architecture\">Claude Code 的记忆架构</a> · <a href=\"/blog/one-person-ai-company\">一个人的 AI 公司</a> · <a href=\"/blog/agent-heartbeat-autonomy\">Agent 心跳自治</a></em></p>\n",
      "date_published": "2026-03-16T00:00:00.000Z",
      "tags": [
        "Agent",
        "架构",
        "Claude Code",
        "实战",
        "系统设计",
        "入门"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "Agent 架构探索"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/agent-heartbeat-autonomy/",
      "url": "https://orbit.mirrorsverse.com/blog/agent-heartbeat-autonomy/",
      "title": "Agent 心跳自治：让 AI 在后台持续工作的工程实践",
      "summary": "让 AI Agent 真正\"自治\"运行，不是靠提示词魔法，而是靠工程设计。本文拆解心跳机制的实现细节：触发方式、约束声明、失败恢复，以及我踩过的那些坑。",
      "content_html": "<p>\"自治 AI\" 听起来很酷，但大多数人的实现是这样的：写一个 while 循环，每隔几分钟让 LLM 执行一次任务，希望它不出错。</p>\n<p>这不是自治，这是轮询加祈祷。</p>\n<p>真正能在生产环境稳定运行的 Agent 自治，需要工程化的心跳机制。本文分享我在 <a href=\"/blog/one-person-ai-company\">Agentic Engineering System</a>（30+ 微服务）中实践出来的方案。</p>\n<p>心跳机制是系统里每个 Agent 的基础能力，与<a href=\"/blog/claude-code-memory-architecture\">五层记忆体系</a>共同构成 Agent 持续运作的骨架。</p>\n<hr />\n<h2>什么是心跳机制</h2>\n<p>心跳（Heartbeat）在分布式系统里是个老概念——节点定期发送信号，证明自己还活着。</p>\n<p>在 Agent 系统里，心跳做的事情更多：</p>\n<ol>\n<li><strong>存活证明</strong>：更新 <code>last_seen</code> 时间戳</li>\n<li><strong>例行检查</strong>：扫描待办任务、检查系统状态</li>\n<li><strong>触发操作</strong>：执行低优先级的后台工作</li>\n<li><strong>约束执行</strong>：在每次循环里校验约束条件没有被破坏</li>\n</ol>\n<p>一个健康的心跳循环，让 Agent 从\"被动响应\"变成\"主动运作\"。</p>\n<hr />\n<h2>心跳文件结构</h2>\n<p>每个 Agent 的 <code>abilities/heartbeat.yaml</code> 定义心跳行为：</p>\n<pre><code># heartbeat.yaml\nagent_id: my_project_agent\nlast_seen: 2026-03-16T10:00:00+08:00\nstatus: active  # active | paused | degraded\n\nschedule:\n  interval: 30m\n  timezone: Asia/Shanghai\n  quiet_hours: \"00:00-07:00\"  # 深夜不执行\n\ntasks:\n  - id: check_requirements\n    desc: 扫描 tasks.yaml，找出 in_progress 和 open 状态的需求\n    priority: high\n\n  - id: update_daily_log\n    desc: 追加今日工作记录到 logs/\n    priority: medium\n\n  - id: sync_knowledge\n    desc: 检查 knowledge 是否有需要更新的文件\n    priority: low\n\nconstraints:\n  hard:\n    - \"不修改任何已发布文章的 slug\"\n    - \"不回滚 tasks.yaml 到更旧的版本\"\n    - \"部署前必须通过 npm run build\"\n    - \"不删除 memory/ 下的任何文件\"\n\n  soft:\n    - \"优先完成 in_progress 状态的需求\"\n    - \"单次心跳不超过 3 个任务\"\n    - \"遇到不确定的决策，记录到 daily.md 等待人工确认\"\n\nrecovery:\n  on_error: log_and_continue  # 单个任务失败不中断整个循环\n  max_retries: 2\n  notify_on_failure: feishu   # 失败时飞书通知\n</code></pre>\n<p>这个文件不只是配置，它是 Agent 的<strong>行为宪法</strong>。</p>\n<hr />\n<h2>触发方式：三种选择</h2>\n<h3>方案一：cron + Claude Code</h3>\n<p>最简单的实现。在终端里：</p>\n<pre><code># 每 30 分钟触发一次\n/loop 30m \"执行心跳任务：检查待办、更新日志、处理低优先级工作\"\n</code></pre>\n<p>优点：零基础设施，立刻能用。\n缺点：依赖终端保持打开，机器睡眠会中断。</p>\n<p>适合：个人开发者日常使用，不要求 24/7。</p>\n<h3>方案二：系统级定时任务</h3>\n<p>在服务器上用 cron 或 Windows Task Scheduler：</p>\n<pre><code># Mac launchd (~/Library/LaunchAgents/com.a9.heartbeat.plist)\n&lt;key&gt;StartInterval&lt;/key&gt;\n&lt;integer&gt;1800&lt;/integer&gt;  &lt;!-- 30分钟 --&gt;\n</code></pre>\n<p>或者直接调用 Agent API：</p>\n<pre><code># crontab -e\n*/30 * * * * curl -s -X POST localhost:8000/api/agent/heartbeat\n</code></pre>\n<p>优点：真正后台运行，机器在线就执行。\n缺点：需要服务一直运行。</p>\n<h3>方案三：Agent 作为常驻服务</h3>\n<p>Agent 内部实现心跳循环，作为 Flask 服务的一部分：</p>\n<pre><code># agent.py (简化示意)\nimport threading\nimport time\n\ndef heartbeat_loop():\n    while True:\n        try:\n            run_heartbeat_tasks()\n        except Exception as e:\n            log_error(e)\n            notify_feishu(f\"心跳异常: {e}\")\n        time.sleep(1800)  # 30分钟\n\n# 在服务启动时\nthreading.Thread(target=heartbeat_loop, daemon=True).start()\n</code></pre>\n<p>这是我现在用的方案——Agent 自己管理自己的心跳，不依赖外部调度器。</p>\n<hr />\n<h2>约束声明：防止 Agent 越界</h2>\n<p>这是整个心跳机制里最容易被忽视、也最重要的部分。</p>\n<p><strong>真实案例</strong>：我的心跳 Agent 在某次循环里扫描到 tasks.yaml 里有一条\"过时的\"需求描述，自作主张把它更新了——但那条描述是我手动写的版本说明，不是错误。</p>\n<p>Agent 没有恶意，它在\"帮忙\"。但帮错了地方。</p>\n<p>解决方案：把每一条血泪教训变成约束声明。</p>\n<pre><code>constraints:\n  hard:\n    - \"不修改任何已发布文章的 slug\"\n    # 原因：slug 变更会导致所有外链 404，SEO 重置\n\n    - \"不回滚 tasks.yaml\"\n    # 原因：曾经踩坑，Agent 把手动版本说明当成错误修复了\n\n    - \"不删除 memory/ 下的任何文件\"\n    # 原因：记忆文件一旦删除，历史上下文永久丢失\n\n    - \"不在没有 build 验证的情况下 push\"\n    # 原因：vite build 不做类型检查，运行时 bug 只在部署后暴露\n</code></pre>\n<p><code>hard</code> 约束是绝对禁止，不管什么情况。<code>soft</code> 约束是偏好，可以在有充分理由时违反。</p>\n<p><strong>写约束的原则</strong>：每条约束后面都应该有注释说明\"为什么\"。没有原因的约束，Agent 在模糊情况下不知道该如何权衡。</p>\n<hr />\n<h2>任务优先级：防止心跳做太多</h2>\n<p>初版心跳设计容易犯的错：任务列表太长，什么都想做。</p>\n<p>结果是：每次心跳运行时间越来越长，一个任务出错会拖累所有任务，上下文窗口被大量\"检查\"类信息占满，真正重要的工作反而做不好。</p>\n<p><strong>实践原则</strong>：</p>\n<pre><code>单次心跳 ≤ 3 个任务\nhigh priority 任务：每次必做\nmedium priority 任务：隔次做\nlow priority 任务：每周做一次\n</code></pre>\n<p>这对应了心跳文件里的 <code>schedule</code> 设计：</p>\n<pre><code>tasks:\n  - id: check_critical_alerts\n    priority: high\n    always_run: true\n\n  - id: update_daily_log\n    priority: medium\n    run_every: 2  # 每2次心跳执行一次\n\n  - id: knowledge_audit\n    priority: low\n    run_on_day: monday  # 每周一\n</code></pre>\n<hr />\n<h2>失败恢复：心跳出错怎么办</h2>\n<p>Agent 心跳失败是正常事件，不是异常情况。关键是<strong>故障隔离</strong>：</p>\n<pre><code>recovery:\n  on_task_error: log_and_continue\n  # 单个任务失败，记录错误，继续下一个任务\n\n  on_critical_error: pause_and_notify\n  # 严重错误（如文件系统不可访问），暂停心跳并通知\n\n  max_consecutive_failures: 3\n  # 连续3次失败后降级为 degraded 状态\n\n  degraded_behavior:\n    - \"只执行 check_critical_alerts\"\n    - \"每次失败都发飞书通知\"\n    - \"等待人工确认后恢复 active\"\n</code></pre>\n<p><code>degraded</code> 状态是关键设计——不是直接停止，而是以最小功能运行，同时发出信号等待干预。</p>\n<hr />\n<h2>每日日志：心跳的记忆痕迹</h2>\n<p>每次心跳执行后，更新 <code>logs/YYYY-MM-DD_daily.md</code>：</p>\n<pre><code>### 10:00 心跳 #42\n- ✅ 检查需求：3 个 in_progress，0 个 blocked\n- ✅ 更新日志：追加本条记录\n- ⏭ 知识审计：跳过（非周一）\n\n### 10:30 心跳 #43\n- ✅ 检查需求：同上\n- ⚠️ 发现：FR-ANC-030 已完成但状态未更新，标记为 implemented\n- ✅ 更新日志\n</code></pre>\n<p>这个日志有两个用途：</p>\n<ol>\n<li><strong>调试</strong>：出问题时能回溯\"心跳 #X 那次做了什么\"</li>\n<li><strong>接续</strong>：人工介入时读最近的日志，立刻了解系统状态</li>\n</ol>\n<hr />\n<h2>状态机：心跳的生命周期</h2>\n<p>Agent 的运行状态不是简单的开/关，是一个状态机：</p>\n<pre><code>[init] → [active] → [paused]\n                 ↓         ↑\n           [degraded] → [active]\n                 ↓\n            [stopped]\n</code></pre>\n<ul>\n<li><code>active</code>：正常运行，按 schedule 执行任务</li>\n<li><code>paused</code>：主动暂停（比如重大变更期间），不执行任务但保持服务</li>\n<li><code>degraded</code>：检测到异常，降级运行，等待人工干预</li>\n<li><code>stopped</code>：服务停止（不同于 paused，不会自动恢复）</li>\n</ul>\n<p>状态存在 <code>heartbeat.yaml</code> 的 <code>status</code> 字段里，每次心跳检查状态，决定是否执行任务。</p>\n<hr />\n<h2>从理论到实践</h2>\n<p>我的系统里现在有 7 个 Agent 同时在跑心跳，覆盖不同的领域和任务。</p>\n<p>几个经验总结：</p>\n<p><strong>不要追求 100% 自动化</strong>。有些决策就应该等人工确认——心跳的 <code>soft</code> 约束里要有\"不确定就记录等待\"的原则。</p>\n<p><strong>约束要持续迭代</strong>。每次发现 Agent 做了不该做的事，第一反应不是骂 AI，而是把这个场景加进约束列表。</p>\n<p><strong>日志是最便宜的保险</strong>。哪怕心跳只做了三件事，也要记录清楚。调试时你会感谢自己。</p>\n<p><strong>心跳间隔要合理</strong>。太短（5分钟）会产生大量无意义的执行记录，太长（24小时）失去了自治的意义。30分钟是我现在用的节奏，覆盖大多数场景。</p>\n<hr />\n<p>自治不是让 AI 无限制地运行，而是在明确的边界里高效地运作。边界越清晰，Agent 越可靠。</p>\n<hr />\n<p><em>系列文章：<a href=\"/blog/series/Agent%20%E6%9E%B6%E6%9E%84%E6%8E%A2%E7%B4%A2\">Agent 架构探索</a> · 上一篇：<a href=\"/blog/one-person-ai-company\">一个人的 AI 公司</a></em></p>\n",
      "date_published": "2026-03-16T00:00:00.000Z",
      "tags": [
        "Agent",
        "架构",
        "实战",
        "自动化",
        "系统设计"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "Agent 架构探索"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/ai-toolkit-2026/",
      "url": "https://orbit.mirrorsverse.com/blog/ai-toolkit-2026/",
      "title": "独立开发者的 AI 工具箱 2026：我实际在用的那些",
      "summary": "不是推荐清单，是我日常真实依赖的工具栈。从编程助手到本地模型，从内容生产到 Agent 系统——每一个都说清楚为什么用它，以及什么情况下不用它。",
      "content_html": "<p>网上的 AI 工具推荐文章有两个共同问题：要么是推广，要么是作者根本没深度用过。</p>\n<p>这篇不一样——全部是我每天在用、付费在用、踩过坑的工具。每个工具我都说清楚<strong>为什么用</strong>和<strong>什么情况下不用</strong>。</p>\n<hr />\n<h2>编程类</h2>\n<h3>Claude Code（核心主力）</h3>\n<p><strong>用途</strong>：几乎所有编程任务的执行层。</p>\n<p>我的工作流：Claude Code 作为常驻终端，配合 <a href=\"/blog/claude-code-memory-architecture\">CLAUDE.md 记忆体系</a>，能持续接续上下文。不只是\"帮我写代码\"，更是\"帮我管理一个工程项目\"。</p>\n<p>真正让它好用的不是 Claude 有多聪明，而是 <a href=\"/blog/claude-code-hooks\">Hooks 系统</a>——给 AI 加上审计层之后，我才真正放心让它执行写文件、运行命令这类操作。</p>\n<p><strong>收费</strong>：$20/月（Claude Pro），值。</p>\n<p><strong>什么时候不用</strong>：纯探索性的对话、不需要操作文件系统的问题，用 Claude.ai 网页版即可，不消耗 Claude Code quota。</p>\n<hr />\n<h3>Cursor（备用）</h3>\n<p><strong>用途</strong>：需要在 IDE 里直接看效果时。</p>\n<p>Cursor 的优势是和代码编辑器深度集成——可以直接在编辑器里接受/拒绝改动，视觉上更直观。</p>\n<p><strong>什么时候不用</strong>：我大多数工作在终端完成，Cursor 的图形界面反而是额外认知负担。如果你是 GUI 优先的开发者，它比 Claude Code 更顺手。</p>\n<hr />\n<h3>GitHub Copilot（已弃用）</h3>\n<p>曾经用了两年。在 Claude Code 出来之后，基本没打开过。</p>\n<p>原因：Copilot 的补全模式适合\"知道方向、需要加速\"的场景；Claude Code 的对话模式适合\"需要 AI 帮你决策\"的场景。我现在更多后者。</p>\n<hr />\n<h2>模型层</h2>\n<h3>Claude Sonnet 4.6（日常主力）</h3>\n<p><strong>用途</strong>：90% 的编程任务、内容生成、分析推理。</p>\n<p>速度和质量的最佳平衡点。Opus 更聪明但慢 3 倍，Haiku 更快但质量下降明显。Sonnet 是我的默认选择。</p>\n<h3>Qwen3-235B（本地高质量推理）</h3>\n<p><strong>用途</strong>：需要本地运行的高质量推理任务。</p>\n<p>在 Mac Studio 上通过 <a href=\"/projects\">omlx</a> 运行，4bit 量化，8.5 分（我的主观评分），接近 Claude 的质量。用于不想把数据发到云端的场景——内部文档分析、本地 Agent 任务。</p>\n<p>详见：<a href=\"/blog/mlx-local-model-mac\">MLX 本地模型运行实践</a>。</p>\n<p><strong>什么时候不用</strong>：需要快速响应时，本地模型延迟明显高于云端 API。</p>\n<h3>MiniMax M2.5（高性价比云端）</h3>\n<p><strong>用途</strong>：中等复杂度任务的云端补充，成本是 Claude 的 1/5。</p>\n<p>我用它跑 Liaison Agent（飞书消息处理），响应速度够快，中文理解好，适合高频低复杂度的 Agent 任务。</p>\n<hr />\n<h2>效率工具</h2>\n<h3>Raycast AI（日常问答）</h3>\n<p><strong>用途</strong>：碎片化问题的快速答案，不想开浏览器时。</p>\n<p><code>⌘ Space</code> → 打字 → 得到答案。比开 Claude.ai 快 10 秒。别小看这 10 秒，一天省下来很可观。</p>\n<h3>Context7 MCP（实时文档）</h3>\n<p><strong>用途</strong>：在 Claude Code 里获取最新的库文档。</p>\n<p><a href=\"/blog/mcp-in-practice\">MCP 协议</a>注册后，Claude 遇到不确定的 API 会自动拉取最新文档，而不是靠训练数据里的旧知识。</p>\n<p>Astro 5、Tailwind v4、Vercel 最新配置——全靠它保持准确。</p>\n<h3>Perplexity（实时信息）</h3>\n<p><strong>用途</strong>：需要引用来源的实时信息查询。</p>\n<p>和 Claude 的区别：Perplexity 适合\"这件事目前是什么状态\"（实时+引用），Claude 适合\"帮我分析这件事\"（推理+生成）。</p>\n<hr />\n<h2>内容创作</h2>\n<h3>Claude.ai（内容生成）</h3>\n<p><strong>用途</strong>：博客文章的初稿、结构设计、文案打磨。</p>\n<p>这个站点上的大多数文章，都经历了这样的流程：我写提纲 → Claude 扩写初稿 → 我大幅修改和注入个人经历 → 发布。</p>\n<p><strong>关键</strong>：Claude 的初稿通常太完整、太正确、太无趣。我的工作是把自己真实的声音注入进去。</p>\n<h3>Notion AI（笔记整理）</h3>\n<p><strong>用途</strong>：把乱糟糟的笔记整理成结构化内容。</p>\n<p>不用它写新东西，只用它整理已有的内容。它在 Notion 环境里的集成体验很好。</p>\n<hr />\n<h2>工具选择的几个原则</h2>\n<p><strong>1. 工具层和模型层分开评估</strong></p>\n<p>Claude Code 好用不等于 Claude 模型最好。工具层（工作流集成）和模型层（推理质量）是两个维度，分开选择。</p>\n<p><strong>2. 深度用两三个，胜过浅度用十个</strong></p>\n<p>我试过很多工具，现在日常用的不超过 8 个。每个都用到很深，理解它的边界在哪里。</p>\n<p><strong>3. 本地 vs 云端：数据敏感度决定</strong></p>\n<p>财务数据、私人文件、内部代码——走本地模型。公开内容、一般任务——走云端 API。不要教条，按数据敏感度分类。</p>\n<p><strong>4. 工具成本要放进总体 ROI 里算</strong></p>\n<p>我每月在 AI 工具上花约 $40（Claude Pro + Perplexity Pro）。对应省下的时间，ROI 轻松超过 10x。但前提是真的深度用了，不是买了放着。</p>\n<hr />\n<h2>2026 年值得关注的方向</h2>\n<p><strong>Agent 基础设施</strong>：不只是单个 AI 工具，而是多个 Agent 协作的系统。我已经在跑的这套 <a href=\"/blog/one-person-ai-company\">30+ 微服务系统</a> 是一个方向。</p>\n<p><strong>本地模型实用化</strong>：Qwen3-235B 4bit 能在 Mac 上跑到接近 Claude 的质量，这个趋势会继续。数据主权会成为越来越多人的考量。</p>\n<p><strong>工具收敛</strong>：AI 工具的数量会从爆炸式增长转向收敛，真正有深度的工具会胜出。</p>\n<hr />\n<p><em>相关文章：<a href=\"/blog/claude-code-memory-architecture\">Claude Code 记忆架构</a> · <a href=\"/blog/mcp-in-practice\">MCP 协议实战</a> · <a href=\"/blog/mlx-local-model-mac\">MLX 本地模型</a> · <a href=\"/blog/one-person-ai-company\">一个人的AI公司</a></em></p>\n",
      "date_published": "2026-03-16T00:00:00.000Z",
      "tags": [
        "AI工具",
        "Claude Code",
        "LLM",
        "效率工具",
        "独立开发",
        "2026"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ]
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/claude-code-15-tips/",
      "url": "https://orbit.mirrorsverse.com/blog/claude-code-15-tips/",
      "title": "Claude Code 15 个实用技巧：从够用到真正好用",
      "summary": "大多数人只用到了 Claude Code 20% 的能力。这 15 个技巧覆盖从上下文管理、工作流加速到防坑实践——每一条都来自真实使用中的摸索。",
      "content_html": "<p>用了 Claude Code 大半年，踩了很多坑，也摸索出一套让它真正好用的方法。</p>\n<p>整理了 15 条，全部来自实际使用，没有\"多用多练\"这种废话。</p>\n<hr />\n<h2>上下文管理</h2>\n<h3>1. CLAUDE.md 是上下文的基础设施，不是笔记本</h3>\n<p>很多人把 CLAUDE.md 当记事本用，什么都往里塞。结果文件越来越长，反而稀释了重要信息。</p>\n<p>正确用法：CLAUDE.md 只放<strong>约束和索引</strong>，不放内容。</p>\n<pre><code># 项目约定\n- 部署前必须 npm run build\n- 不修改已发布文章的 slug\n\n# 知识在哪里找\n- 架构决策 → memory/knowledge/\n- 上次进度 → memory/logs/最近日期_daily.md\n- 部署流程 → memory/skills/deploy.md\n</code></pre>\n<p>控制在 50 行以内。细节放到 memory 层级，CLAUDE.md 只做指针。</p>\n<h3>2. 用 <code>/clear</code> 而不是新开窗口</h3>\n<p>上下文窗口满了，很多人的反应是关掉终端重开。正确做法是 <code>/clear</code> 清空对话历史，但保留 CLAUDE.md 加载的上下文。</p>\n<p>重开窗口会重新读 CLAUDE.md，效果一样，但 <code>/clear</code> 更快。</p>\n<h3>3. 用 <code>#</code> 引用文件，而不是\"你去看 xxx 文件\"</h3>\n<pre><code>❌ \"你去看 src/components/SearchDialog.tsx\"\n✅ \"修改 #src/components/SearchDialog.tsx 的搜索结果布局\"\n</code></pre>\n<p><code>#</code> 前缀让 Claude 立刻读取文件，而不是等到它自己决定要不要读。在上下文有限时，这个区别很重要。</p>\n<h3>4. 长任务开始前先写 Plan</h3>\n<p>对于超过 3 步的任务，先让 Claude 写一个执行计划，确认后再开始执行：</p>\n<pre><code>先给我写一个实现计划，不要开始写代码。\n计划确认后我会说\"开始执行\"。\n</code></pre>\n<p>这避免了 Claude 理解偏差导致的大段无效代码。</p>\n<hr />\n<h2>工作流加速</h2>\n<h3>5. <code>/loop</code> 让重复任务自动化</h3>\n<p>Claude Code 支持循环执行：</p>\n<pre><code>/loop 30m \"检查 tasks.yaml 待办，处理一条 in_progress 需求\"\n</code></pre>\n<p>适合：定时同步、心跳检查、内容批量处理。不适合：需要实时判断的复杂任务。</p>\n<h3>6. 用任务文件替代长对话</h3>\n<p>超过 10 轮的对话，信息密度下降，Claude 容易\"忘事\"。更好的方式：</p>\n<p>把任务写成 markdown 文件，每次执行时读文件：</p>\n<pre><code>读取 tasks/current-sprint.md，按优先级处理第一条未完成任务。\n完成后在文件里标记状态，再告诉我结果。\n</code></pre>\n<p>任务状态在文件里持久化，不依赖对话历史。</p>\n<h3>7. 用 <code>--dangerously-skip-permissions</code> 解放生产力（谨慎使用）</h3>\n<p>在已建立信任的项目里，每次工具调用都要确认会极大拖慢速度。</p>\n<p>在受控环境（已配置 Hooks 的项目）里可以跳过权限确认：</p>\n<pre><code>claude --dangerously-skip-permissions\n</code></pre>\n<p><strong>前提</strong>：必须先配置好 <a href=\"/blog/claude-code-hooks\">Hooks</a> 做安全兜底，不然等于裸奔。</p>\n<h3>8. Git worktree 做实验性修改</h3>\n<p>不确定 Claude 的改动是否正确时，用 git worktree 隔离：</p>\n<pre><code>git worktree add ../experiment-branch -b experiment\ncd ../experiment-branch\n# 让 Claude 在这里做修改\n# 满意了再 merge，不满意直接删\n</code></pre>\n<p>Claude Code 对 worktree 的支持很好，能正确识别当前工作目录。</p>\n<hr />\n<h2>提示词技巧</h2>\n<h3>9. 给 Claude 角色，而不是只给任务</h3>\n<pre><code>❌ \"重构这个函数\"\n✅ \"你是一个 Python 性能工程师，重构这个函数，重点关注减少不必要的内存分配\"\n</code></pre>\n<p>角色定义给 Claude 一个判断框架，输出质量会明显提升。</p>\n<h3>10. 用\"不要做什么\"约束输出范围</h3>\n<p>Claude 倾向于\"帮忙做更多\"，但有时候你只想要最小改动：</p>\n<pre><code>只修改 getUser 函数的错误处理逻辑。\n不要重构其他函数，不要添加类型注解，不要修改函数签名。\n</code></pre>\n<p>明确说\"不要做什么\"，比说\"只做这一件事\"更有效。</p>\n<h3>11. 要求 Claude 先解释再修改</h3>\n<p>对于重要文件，先让 Claude 解释当前代码的逻辑，再提修改：</p>\n<pre><code>先解释 auth.py 里 verify_token 函数的工作原理，\n特别是 token 过期的处理逻辑。\n理解后我再告诉你要改什么。\n</code></pre>\n<p>这一步能暴露 Claude 是否真正理解了代码，避免盲目修改。</p>\n<hr />\n<h2>防坑实践</h2>\n<h3>12. 每次重要操作后立刻 git commit</h3>\n<p>不要攒着一起提交。Claude 做了 5 件事，你只想撤销第 3 件——很麻烦。</p>\n<p>养成习惯：Claude 完成一个独立功能 → 立刻 commit → 继续下一个。</p>\n<pre><code>完成了，帮我写一个 git commit message，然后我来 commit。\n</code></pre>\n<h3>13. 让 Claude 写测试，而不是\"帮我验证\"</h3>\n<pre><code>❌ \"你觉得这段代码对吗？\"\n✅ \"为这个函数写 3 个边界用例的单元测试，包括空输入和超大输入\"\n</code></pre>\n<p>Claude 自己评估自己写的代码，容易产生确认偏差。测试用例是更客观的验证方式。</p>\n<h3>14. 用 <code>/cost</code> 追踪费用，避免账单冲击</h3>\n<p>长会话的 token 消耗会超出预期。定期查看：</p>\n<pre><code>/cost\n</code></pre>\n<p>如果发现费用飙升，通常是某个任务在循环消耗上下文。找到后 <code>/clear</code> 重置。</p>\n<h3>15. 保存有效的提示词到 CLAUDE.md</h3>\n<p>当你发现某个提示词特别有效，不要让它消失在对话历史里：</p>\n<pre><code># 有效提示词模板\n\n## 代码审查\n\"以安全工程师视角审查这段代码，重点找 injection 漏洞和权限边界问题\"\n\n## 重构\n\"最小化改动重构，保持函数签名不变，只改内部实现\"\n\n## 调试\n\"不要立刻给解决方案。先列出 3 个最可能的原因，我来确认方向\"\n</code></pre>\n<p>好的提示词是可复用资产，对待它就像对待代码一样。</p>\n<hr />\n<h2>一个元技巧</h2>\n<p>所有这些技巧背后有一个共同逻辑：<strong>把你的隐性知识显性化，放进 Claude 能读到的地方</strong>。</p>\n<p>你知道的约束、你踩过的坑、你喜欢的代码风格——这些都应该在某个文件里，而不是在你的脑子里靠每次对话重新传递。</p>\n<p>这是 Claude Code 和普通 AI 对话框最大的区别：它可以积累上下文，前提是你愿意建设这个上下文。</p>\n<hr />\n<p><em>系列文章：<a href=\"/blog/series/Claude%20Code%20%E5%AE%9E%E6%88%98\">Claude Code 实战</a> · 相关：<a href=\"/blog/claude-code-memory-architecture\">记忆架构</a> · <a href=\"/blog/claude-code-hooks\">Hooks 实战</a> · <a href=\"/blog/mcp-in-practice\">MCP 实战</a></em></p>\n",
      "date_published": "2026-03-16T00:00:00.000Z",
      "tags": [
        "Claude Code",
        "Claude",
        "实战",
        "开发效率",
        "技巧"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "Claude Code 实战"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/claude-code-hooks/",
      "url": "https://orbit.mirrorsverse.com/blog/claude-code-hooks/",
      "title": "Claude Code Hooks：让 AI 编程有迹可循、可审计、可回滚",
      "summary": "Claude Code 的 Hooks 系统让你能在 AI 执行操作的前后注入自定义逻辑——自动备份、风险拦截、操作日志、通知推送。这是从\"信任 AI\"到\"验证 AI\"的关键一步。",
      "content_html": "<p>大多数人用 Claude Code 的方式是：给指令，看结果，如果不对就撤销。</p>\n<p>这能工作，但有一个隐患：<strong>你不知道 AI 做了什么，直到它做完</strong>。</p>\n<p>Claude Code 的 Hooks 系统解决了这个问题。它让你能在 AI 执行每一步操作的前后注入自定义逻辑——不只是\"允许还是拒绝\"，而是完整的可编程拦截层。</p>\n<hr />\n<h2>Hooks 是什么</h2>\n<p>Hooks 是 Claude Code 在特定事件发生时自动执行的 shell 命令。</p>\n<p>目前支持四种 Hook 事件：</p>\n<table>\n<thead>\n<tr>\n<th>Hook</th>\n<th>触发时机</th>\n</tr>\n</thead>\n<tbody><tr>\n<td><code>PreToolUse</code></td>\n<td>AI 调用任何工具<strong>之前</strong></td>\n</tr>\n<tr>\n<td><code>PostToolUse</code></td>\n<td>AI 调用任何工具<strong>之后</strong></td>\n</tr>\n<tr>\n<td><code>Notification</code></td>\n<td>Claude Code 发出通知时</td>\n</tr>\n<tr>\n<td><code>Stop</code></td>\n<td>Claude Code 完成响应时</td>\n</tr>\n</tbody></table>\n<p>每个 Hook 可以：</p>\n<ul>\n<li><strong>接收</strong> 工具调用的完整上下文（工具名、参数、结果）</li>\n<li><strong>执行</strong> 任意 shell 命令</li>\n<li><strong>影响</strong> 工具调用的行为（PreToolUse 可以阻止执行）</li>\n</ul>\n<hr />\n<h2>配置方式</h2>\n<p>Hooks 在 <code>~/.claude/settings.json</code> 里配置：</p>\n<pre><code>{\n  \"hooks\": {\n    \"PreToolUse\": [\n      {\n        \"matcher\": \"Bash\",\n        \"hooks\": [\n          {\n            \"type\": \"command\",\n            \"command\": \"~/.claude/hooks/pre-bash.sh\"\n          }\n        ]\n      }\n    ],\n    \"PostToolUse\": [\n      {\n        \"matcher\": \"Write\",\n        \"hooks\": [\n          {\n            \"type\": \"command\",\n            \"command\": \"~/.claude/hooks/post-write.sh\"\n          }\n        ]\n      }\n    ]\n  }\n}\n</code></pre>\n<p><code>matcher</code> 支持工具名（<code>Bash</code>、<code>Write</code>、<code>Edit</code>、<code>Read</code> 等）或 <code>*</code>（匹配所有工具）。</p>\n<hr />\n<h2>实战用例一：危险命令拦截</h2>\n<p>最常见的需求：阻止 AI 执行某些高风险操作。</p>\n<p><code>~/.claude/hooks/pre-bash.sh</code>：</p>\n<pre><code>#!/bin/bash\n# 读取工具调用的 JSON 输入\nINPUT=$(cat)\nCOMMAND=$(echo \"$INPUT\" | jq -r '.tool_input.command // \"\"')\n\n# 拦截危险操作\nDANGEROUS_PATTERNS=(\n  \"rm -rf /\"\n  \"git push --force\"\n  \"DROP TABLE\"\n  \"chmod 777\"\n  \"&gt; /dev/sda\"\n)\n\nfor pattern in \"${DANGEROUS_PATTERNS[@]}\"; do\n  if echo \"$COMMAND\" | grep -qi \"$pattern\"; then\n    echo \"🚫 Hook 拦截：检测到危险命令模式 '$pattern'\" &gt;&amp;2\n    # 退出码 2 = 阻止工具执行并显示错误\n    exit 2\n  fi\ndone\n\nexit 0\n</code></pre>\n<p>Hook 的退出码决定行为：</p>\n<ul>\n<li><code>0</code> — 允许执行</li>\n<li><code>1</code> — 记录警告但允许执行</li>\n<li><code>2</code> — <strong>阻止执行</strong>，向 Claude 返回错误信息</li>\n</ul>\n<hr />\n<h2>实战用例二：文件修改自动备份</h2>\n<p>每次 AI 写文件之前，先备份一份：</p>\n<p><code>~/.claude/hooks/pre-write.sh</code>：</p>\n<pre><code>#!/bin/bash\nINPUT=$(cat)\nFILE_PATH=$(echo \"$INPUT\" | jq -r '.tool_input.file_path // \"\"')\n\nif [ -f \"$FILE_PATH\" ]; then\n  BACKUP_DIR=\"$HOME/.claude/backups/$(date +%Y%m%d)\"\n  mkdir -p \"$BACKUP_DIR\"\n\n  # 保留目录结构\n  RELATIVE_PATH=$(echo \"$FILE_PATH\" | sed 's|/|_|g')\n  cp \"$FILE_PATH\" \"$BACKUP_DIR/${RELATIVE_PATH}.bak\"\n\n  echo \"✅ 已备份: $FILE_PATH → $BACKUP_DIR\" &gt;&amp;2\nfi\n\nexit 0\n</code></pre>\n<p>这样即使 AI 写坏了文件，<code>~/.claude/backups/</code> 里永远有当天的版本。</p>\n<hr />\n<h2>实战用例三：操作日志</h2>\n<p>记录 Claude Code 所有工具调用，方便事后审计：</p>\n<p><code>~/.claude/hooks/audit-log.sh</code>：</p>\n<pre><code>#!/bin/bash\nINPUT=$(cat)\nTOOL_NAME=$(echo \"$INPUT\" | jq -r '.tool_name // \"unknown\"')\nTIMESTAMP=$(date -u +\"%Y-%m-%dT%H:%M:%SZ\")\nLOG_FILE=\"$HOME/.claude/audit.log\"\n\n# 提取关键参数（避免记录完整文件内容）\ncase \"$TOOL_NAME\" in\n  \"Bash\")\n    DETAIL=$(echo \"$INPUT\" | jq -r '.tool_input.command // \"\"' | head -c 200)\n    ;;\n  \"Write\"|\"Edit\")\n    DETAIL=$(echo \"$INPUT\" | jq -r '.tool_input.file_path // \"\"')\n    ;;\n  \"Read\"|\"Glob\"|\"Grep\")\n    DETAIL=$(echo \"$INPUT\" | jq -r '.tool_input.file_path // .tool_input.pattern // \"\"')\n    ;;\n  *)\n    DETAIL=$(echo \"$INPUT\" | jq -r '.tool_input | to_entries[0].value // \"\"' | head -c 100)\n    ;;\nesac\n\necho \"$TIMESTAMP | $TOOL_NAME | $DETAIL\" &gt;&gt; \"$LOG_FILE\"\nexit 0\n</code></pre>\n<p>配置到所有工具的 PostToolUse：</p>\n<pre><code>{\n  \"hooks\": {\n    \"PostToolUse\": [\n      {\n        \"matcher\": \"*\",\n        \"hooks\": [{ \"type\": \"command\", \"command\": \"~/.claude/hooks/audit-log.sh\" }]\n      }\n    ]\n  }\n}\n</code></pre>\n<p>一天下来，<code>audit.log</code> 会记录 Claude 做的每一件事。</p>\n<hr />\n<h2>实战用例四：飞书完成通知</h2>\n<p>长任务结束时推送通知，不用盯着屏幕等：</p>\n<p><code>~/.claude/hooks/notify-done.sh</code>：</p>\n<pre><code>#!/bin/bash\nINPUT=$(cat)\n# Stop hook 触发：Claude 完成了一轮响应\n\n# 从环境变量读取飞书 webhook\nif [ -z \"$FEISHU_WEBHOOK\" ]; then exit 0; fi\n\ncurl -s -X POST \"$FEISHU_WEBHOOK\" \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"msg_type\": \"text\",\n    \"content\": { \"text\": \"✅ Claude Code 任务完成\" }\n  }' &gt; /dev/null\n\nexit 0\n</code></pre>\n<p>在 <code>settings.json</code> 的 <code>Stop</code> hook 里注册，长编译或大规模重构完成后，手机飞书就收到通知。</p>\n<hr />\n<h2>组合：完整的安全 + 可观测配置</h2>\n<p>把上面的 hooks 组合在一起：</p>\n<pre><code>{\n  \"hooks\": {\n    \"PreToolUse\": [\n      {\n        \"matcher\": \"Bash\",\n        \"hooks\": [{ \"type\": \"command\", \"command\": \"~/.claude/hooks/pre-bash.sh\" }]\n      },\n      {\n        \"matcher\": \"Write\",\n        \"hooks\": [{ \"type\": \"command\", \"command\": \"~/.claude/hooks/pre-write.sh\" }]\n      }\n    ],\n    \"PostToolUse\": [\n      {\n        \"matcher\": \"*\",\n        \"hooks\": [{ \"type\": \"command\", \"command\": \"~/.claude/hooks/audit-log.sh\" }]\n      }\n    ],\n    \"Stop\": [\n      {\n        \"matcher\": \"*\",\n        \"hooks\": [{ \"type\": \"command\", \"command\": \"~/.claude/hooks/notify-done.sh\" }]\n      }\n    ]\n  }\n}\n</code></pre>\n<p>这套配置实现了：</p>\n<ul>\n<li>🛡 危险命令自动拦截</li>\n<li>💾 文件修改前自动备份</li>\n<li>📋 所有操作完整审计日志</li>\n<li>📱 任务完成飞书通知</li>\n</ul>\n<hr />\n<h2>Hook 脚本的几个设计原则</h2>\n<p><strong>1. 保持快速</strong></p>\n<p>每个工具调用都会触发 Hook，慢 Hook 会明显拖慢 Claude Code 的响应速度。避免在 Hook 里做网络请求（除非是非阻塞的 Stop Hook）。</p>\n<p><strong>2. 静默失败</strong></p>\n<p>Hook 脚本里的错误不应该崩溃 Claude Code。在脚本里加 <code>set +e</code>，确保即使 Hook 出错，也不影响主流程。</p>\n<p><strong>3. 用 stderr 输出诊断信息</strong></p>\n<p>Hook 的 stdout 会传给 Claude，stderr 才是给用户看的日志。诊断信息一律写 stderr：</p>\n<pre><code>echo \"debug: processing $FILE_PATH\" &gt;&amp;2  # 正确\necho \"debug: processing $FILE_PATH\"      # 会被 Claude 读到\n</code></pre>\n<p><strong>4. 幂等设计</strong></p>\n<p>同一操作被触发多次，效果应该相同。备份脚本里用时间戳命名，避免覆盖。</p>\n<hr />\n<h2>与记忆系统结合</h2>\n<p>Hooks 和<a href=\"/blog/claude-code-memory-architecture\">记忆架构</a>可以结合使用。</p>\n<p>比如，在 PostToolUse 里自动更新 Agent 的操作日志到 <code>logs/</code>：</p>\n<pre><code>#!/bin/bash\nINPUT=$(cat)\nTOOL=$(echo \"$INPUT\" | jq -r '.tool_name')\nDETAIL=$(echo \"$INPUT\" | jq -r '.tool_input | tostring' | head -c 100)\nDAILY_LOG=\"./memory/logs/$(date +%Y-%m-%d)_ops.md\"\n\necho \"- $(date +%H:%M) [$TOOL] $DETAIL\" &gt;&gt; \"$DAILY_LOG\"\nexit 0\n</code></pre>\n<p>这样 Agent 的每次操作都自动沉淀进记忆，下次会话能复盘\"上次到底做了什么\"。</p>\n<hr />\n<p>Hooks 系统把 Claude Code 从\"黑盒 AI\"变成了\"可观测、可审计、可干预的工程工具\"。</p>\n<p>从信任，到验证——这才是在生产环境放心使用 AI 的正确姿势。</p>\n<hr />\n<p><em>系列文章：<a href=\"/blog/series/Claude%20Code%20%E5%AE%9E%E6%88%98\">Claude Code 实战</a> · 相关阅读：<a href=\"/blog/claude-code-memory-architecture\">Claude Code 的记忆架构</a> · <a href=\"/blog/mcp-in-practice\">MCP 协议实战</a></em></p>\n",
      "date_published": "2026-03-16T00:00:00.000Z",
      "tags": [
        "Claude Code",
        "Claude",
        "Agent",
        "实战",
        "开发效率",
        "自动化"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "Claude Code 实战"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/claude-code-memory-architecture/",
      "url": "https://orbit.mirrorsverse.com/blog/claude-code-memory-architecture/",
      "title": "Claude Code 的记忆架构：如何让 AI 真正记住你的项目",
      "summary": "大多数人用 Claude Code 的方式是错的——每次对话都从零开始，反复解释背景。本文分享我在真实多 Agent 系统中摸索出的五层记忆架构，让 AI 持续积累项目知识。",
      "content_html": "<p>大多数人用 Claude Code 的姿势是这样的：</p>\n<p>打开终端，开始一个新会话，然后花 5 分钟解释\"我的项目是做什么的、用什么技术栈、现在遇到什么问题\"……</p>\n<p>下次打开，再解释一遍。</p>\n<p>这不是 Claude Code 该有的使用方式。</p>\n<hr />\n<h2>为什么 AI 不记得你？</h2>\n<p>Claude Code 本质上是无状态的——每次对话都是全新的上下文窗口。它不会自动记住上次你说过什么，除非你把信息放进它能读到的地方。</p>\n<p>问题不在于 Claude 不够聪明，而在于<strong>你没有给它一个持久化的记忆系统</strong>。</p>\n<p>好消息是：Claude Code 本身就提供了这个能力，只是大多数人没用好。</p>\n<hr />\n<h2>五层记忆架构</h2>\n<p>我在自己的 Agentic Engineering System（30+ 微服务的多 Agent 系统）里，为每个 Agent 设计了五层记忆体系：</p>\n<pre><code>memory/\n├── character/    # Agent 人格与价值观\n├── abilities/    # 能力声明（会做什么、不会做什么）\n├── skills/       # 操作规程（SOP）\n├── knowledge/    # 结构化领域知识\n└── logs/  # 日志、讨论、临时信息\n</code></pre>\n<p>这个结构不是凭空想出来的，是在每天使用中迭代出来的。</p>\n<h3>第 0 层：Character（人格）</h3>\n<p>这一层定义 Agent 是\"谁\"——它的角色、价值观、行为边界。</p>\n<pre><code># 角色定位\n我是 AI Navigator Coordinator，负责管理 my-project.example.com 的\n内容规划和功能迭代。\n\n## 核心原则\n- 每次部署前必须 build 验证\n- 不修改已发布文章的 slug（影响 SEO）\n- 重要决策记录到 knowledge/\n</code></pre>\n<p>Character 文件很少变动，但它决定了 Agent 在面对模糊指令时的判断基准。</p>\n<h3>第 1 层：Abilities（能力声明）</h3>\n<p>心跳 + 能力边界。Agent 每隔一段时间更新这里，证明自己\"还活着\"并且知道自己的职责范围。</p>\n<p>最关键的是<strong>明确写出不该做的事</strong>：</p>\n<pre><code># heartbeat.yaml\nlast_seen: 2026-03-16T10:00:00\nstatus: active\n\nconstraints:\n  - do_not_modify: \"src/content/blog/*/slug\"\n  - do_not_revert: \"tasks.yaml\"\n  - always_build_before_deploy: true\n</code></pre>\n<p>这层解决了一个真实的坑：我的心跳 Agent 曾经把 tasks.yaml 回滚到旧版本，就是因为 Abilities 层缺少约束声明。</p>\n<h3>第 2 层：Skills（操作规程）</h3>\n<p>可复用的操作步骤，类似 SOP。每次需要做某件事，不是临时摸索，而是执行已验证的 skill。</p>\n<p>比如部署博客的 skill：</p>\n<pre><code># deploy-blog.md\n\n## 前置检查\n1. git pull 拉取最新\n2. npm run build 验证无错误\n3. 检查 dist/sitemap-index.xml 包含新页面\n\n## 执行\ngit add -A &amp;&amp; git commit -m \"...\" &amp;&amp; git push\n\n## 验证\n等待 Vercel 部署完成（~2分钟），访问新页面确认\n</code></pre>\n<p>Skill 的价值在于<strong>把踩过的坑固化成流程</strong>，不反复踩。</p>\n<h3>第 3 层：Knowledge（结构化知识）</h3>\n<p>项目的\"大脑\"。包含：</p>\n<ul>\n<li>架构决策及其原因（ADR）</li>\n<li>技术栈选型说明</li>\n<li>已知问题和解决方案</li>\n<li>业务规则</li>\n</ul>\n<p>我的经验是<strong>每个知识文件保持单一主题，100 行以内</strong>。文件太大，Claude 的注意力会分散。</p>\n<pre><code>knowledge/\n├── site-architecture.md      # 站点结构\n├── seo-strategy.md           # SEO 策略\n├── deployment-config.md      # 部署配置\n└── content-guidelines.md     # 内容规范\n</code></pre>\n<h3>第 4 层：Information（日志与讨论）</h3>\n<p>时效性信息：工作日志、讨论记录、临时决策。</p>\n<p>每天一个 <code>YYYY-MM-DD_daily.md</code>，记录：</p>\n<ul>\n<li>做了什么</li>\n<li>遇到什么问题</li>\n<li>明天要做什么</li>\n</ul>\n<p>这层不求精，求<strong>持续记录</strong>。Claude 在新会话里读这些日志，能快速恢复\"上次我们做到哪里了\"的状态。</p>\n<hr />\n<h2>CLAUDE.md：记忆的入口</h2>\n<p>光有记忆文件还不够，你需要一个\"索引\"——让 Claude 知道这些记忆在哪里、应该在什么时候读。</p>\n<p>这就是 <code>CLAUDE.md</code> 的作用。</p>\n<p>每个项目根目录放一个 <code>CLAUDE.md</code>，写清楚：</p>\n<pre><code># 项目概要\n- 产品名：AI时代漫游指南\n- 技术栈：Astro 5 + Tailwind + Vercel\n- 重要约定：部署前必须 npm run build\n\n## 记忆结构\n- knowledge/：架构决策、配置说明\n- logs/：日志在这里找上次进度\n\n## 常用命令\n- 开发：npm run dev\n- 构建：npm run build\n- 部署：git push（Vercel 自动）\n</code></pre>\n<p>Claude Code 每次启动都会读 <code>CLAUDE.md</code>，这是它接入项目记忆的第一个锚点。</p>\n<hr />\n<h2>实战效果</h2>\n<p>用了这套架构之后，我的工作流变成：</p>\n<ol>\n<li>打开终端，Claude Code 自动读 CLAUDE.md</li>\n<li>说\"继续昨天的工作\"——它读 daily.md，知道上次做到哪里</li>\n<li>说\"按照 skill 部署\"——它执行已验证的流程，不乱来</li>\n<li>工作完成，更新 daily.md，下次无缝接续</li>\n</ol>\n<p>最关键的变化：<strong>我不再需要反复解释背景</strong>。Claude 变成了真正意义上的持续合作者，而不是一个每次都失忆的助手。</p>\n<hr />\n<h2>常见误区</h2>\n<p><strong>误区 1：把所有信息都塞进 CLAUDE.md</strong></p>\n<p>CLAUDE.md 只应该是索引和最关键的约定，不超过 100 行。细节放到对应的 memory 层级里。</p>\n<p><strong>误区 2：记忆文件只写不读</strong></p>\n<p>如果你不在 CLAUDE.md 里指引 Claude 去读这些文件，它不会主动读。要明确告诉它\"遇到部署问题看 skills/\"。</p>\n<p><strong>误区 3：知识文件越详细越好</strong></p>\n<p>适度即可。过于详细的文件会稀释重要信息。每个文件聚焦一个主题，保持可读性。</p>\n<hr />\n<h2>下一步</h2>\n<p>如果你现在的项目没有任何记忆结构，从最小可行版本开始：</p>\n<ol>\n<li>建一个 <code>CLAUDE.md</code>，写 3-5 条最重要的约定</li>\n<li>建一个 <code>notes/daily.md</code>，开始记录工作日志</li>\n<li>当某个操作流程你做了第二遍，把它写成 skill</li>\n</ol>\n<p>记忆系统不是一次性建好的，是在每次使用中慢慢生长的。</p>\n<hr />\n<p><em>本文基于在 Agentic Engineering System（30+ Agent 微服务）中的真实实践，当前系统已稳定运行 3 个月。</em></p>\n",
      "date_published": "2026-03-16T00:00:00.000Z",
      "tags": [
        "Claude Code",
        "Claude",
        "Agent",
        "架构",
        "实战"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "Claude Code 实战"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/mcp-in-practice/",
      "url": "https://orbit.mirrorsverse.com/blog/mcp-in-practice/",
      "title": "MCP 协议实战：给你的 AI 装上真正的手和眼",
      "summary": "MCP（Model Context Protocol）让 AI 能够调用真实工具、读取实时数据。本文从原理到实战，带你真正用起来——不只是理解概念，而是搭出一个能工作的 MCP 服务器。",
      "content_html": "<p>AI 最大的局限之一：它只能用你喂给它的信息。</p>\n<p>你问它今天的新闻，它不知道。你让它查你的数据库，它做不到。你希望它操作你的文件系统，它只能靠猜。</p>\n<p>MCP（Model Context Protocol）就是为了解决这个问题而生的——给 AI 装上手和眼，让它能真正触及外部世界。</p>\n<hr />\n<h2>MCP 是什么</h2>\n<p>MCP 是 Anthropic 提出的开放协议，定义了 AI 模型与外部工具/数据源之间的通信标准。</p>\n<p>简单理解：它是一套规范，让任何人都能写一个\"工具服务器\"，AI 客户端（如 Claude Code）可以发现这些服务器并调用里面的工具。</p>\n<pre><code>Claude Code ←→ MCP 协议 ←→ MCP 服务器（你写的）\n                               ├── 读取文件\n                               ├── 查询数据库\n                               ├── 调用 API\n                               └── 执行命令\n</code></pre>\n<p>MCP 之前，每个 AI 工具都要自己定义工具调用格式，彼此不兼容。MCP 之后，写一次服务器，所有支持 MCP 的客户端都能用。</p>\n<hr />\n<h2>核心概念：三种能力</h2>\n<p>MCP 服务器可以暴露三种能力：</p>\n<h3>Tools（工具）</h3>\n<p>AI 可以主动调用的函数。类似 function calling，但标准化了。</p>\n<pre><code>{\n  \"name\": \"search_posts\",\n  \"description\": \"搜索博客文章\",\n  \"inputSchema\": {\n    \"type\": \"object\",\n    \"properties\": {\n      \"query\": { \"type\": \"string\" }\n    }\n  }\n}\n</code></pre>\n<h3>Resources（资源）</h3>\n<p>AI 可以读取的数据。文件、数据库记录、API 响应都可以包装成 Resource。</p>\n<pre><code>{\n  \"uri\": \"file:///data/posts.json\",\n  \"mimeType\": \"application/json\",\n  \"description\": \"所有博客文章的元数据\"\n}\n</code></pre>\n<h3>Prompts（提示模板）</h3>\n<p>预置的对话模板，用户可以通过斜杠命令触发。</p>\n<p>这三者可以单独使用，也可以混合——一个 MCP 服务器通常同时提供 Tools 和 Resources。</p>\n<hr />\n<h2>动手：搭一个最小 MCP 服务器</h2>\n<p>用 Python 官方 SDK（<code>mcp</code>），实现一个能查询本地 markdown 文章的工具服务器：</p>\n<h3>安装</h3>\n<pre><code>pip install mcp\n</code></pre>\n<h3>代码</h3>\n<pre><code># blog_mcp_server.py\nfrom mcp.server import Server\nfrom mcp.server.stdio import stdio_server\nfrom mcp.types import Tool, TextContent\nimport json\nimport os\nfrom pathlib import Path\n\napp = Server(\"blog-tools\")\n\nPOSTS_DIR = Path(\"./src/content/blog\")\n\n@app.list_tools()\nasync def list_tools():\n    return [\n        Tool(\n            name=\"search_posts\",\n            description=\"在博客文章中搜索关键词，返回匹配的文章标题和摘要\",\n            inputSchema={\n                \"type\": \"object\",\n                \"properties\": {\n                    \"query\": {\n                        \"type\": \"string\",\n                        \"description\": \"搜索关键词\"\n                    }\n                },\n                \"required\": [\"query\"]\n            }\n        ),\n        Tool(\n            name=\"get_post\",\n            description=\"读取指定 slug 的文章全文\",\n            inputSchema={\n                \"type\": \"object\",\n                \"properties\": {\n                    \"slug\": {\n                        \"type\": \"string\",\n                        \"description\": \"文章的 slug（文件名不含 .md）\"\n                    }\n                },\n                \"required\": [\"slug\"]\n            }\n        )\n    ]\n\n@app.call_tool()\nasync def call_tool(name: str, arguments: dict):\n    if name == \"search_posts\":\n        query = arguments[\"query\"].lower()\n        results = []\n        for f in POSTS_DIR.glob(\"*.md\"):\n            content = f.read_text(encoding=\"utf-8\")\n            if query in content.lower():\n                # 提取标题（frontmatter 第一行 title:）\n                title = next((l.split(\":\", 1)[1].strip().strip(\"'\\\"\")\n                              for l in content.splitlines()\n                              if l.startswith(\"title:\")), f.stem)\n                results.append({\"slug\": f.stem, \"title\": title})\n        return [TextContent(type=\"text\", text=json.dumps(results, ensure_ascii=False))]\n\n    elif name == \"get_post\":\n        slug = arguments[\"slug\"]\n        post_file = POSTS_DIR / f\"{slug}.md\"\n        if not post_file.exists():\n            return [TextContent(type=\"text\", text=f\"文章 {slug} 不存在\")]\n        return [TextContent(type=\"text\", text=post_file.read_text(encoding=\"utf-8\"))]\n\nif __name__ == \"__main__\":\n    import asyncio\n    asyncio.run(stdio_server(app))\n</code></pre>\n<h3>注册到 Claude Code</h3>\n<p>在 <code>~/.claude/claude_desktop_config.json</code>（或 Claude Code 的 MCP 配置文件）里添加：</p>\n<pre><code>{\n  \"mcpServers\": {\n    \"blog-tools\": {\n      \"command\": \"python\",\n      \"args\": [\"/path/to/blog_mcp_server.py\"]\n    }\n  }\n}\n</code></pre>\n<p>重启 Claude Code，现在你可以直接说：</p>\n<blockquote>\n<p>\"搜索所有关于 Agent 的文章\"\n\"读一下 one-person-ai-company 这篇文章\"</p>\n</blockquote>\n<p>Claude 会自动调用你的工具，而不是凭印象回答。</p>\n<hr />\n<h2>真实用例：我在用的 MCP 工具</h2>\n<h3>context7 — 实时文档查询</h3>\n<p>这是我用得最多的 MCP 工具。当 Claude Code 需要某个库的最新 API 时，context7 直接从源头拉文档，不靠训练数据里的旧知识。</p>\n<pre><code># Claude.md 里配置\n使用 context7 获取最新文档，避免用过时的 API\n</code></pre>\n<p>效果：Astro 5 的新语法、Vercel 的最新配置，全部实时准确。</p>\n<h3>文件系统工具</h3>\n<p>Claude Code 内置的文件读写工具本质上就是 MCP 工具——这也是为什么它能直接编辑你的代码而不只是生成代码片段。</p>\n<h3>自定义飞书工具</h3>\n<p>我给系统里的 Agent 写了飞书 MCP 工具，让 Claude 能直接发消息到飞书群、读取最近的对话记录。</p>\n<p>核心工具：</p>\n<ul>\n<li><code>send_feishu_message(chat_id, text)</code> — 发消息</li>\n<li><code>get_recent_messages(chat_id, count)</code> — 读最近 N 条</li>\n<li><code>create_task(title, assignee)</code> — 创建飞书任务</li>\n</ul>\n<p>这让\"AI 回复飞书消息\"变成了可靠的工作流，而不是脆弱的字符串拼接。</p>\n<hr />\n<h2>设计好 MCP 工具的原则</h2>\n<p>用了一段时间之后，几点心得：</p>\n<p><strong>1. 工具描述要像写给人看的</strong></p>\n<p>AI 通过 <code>description</code> 字段决定什么时候用这个工具。描述不清楚，工具就会被误用或不被使用。</p>\n<p>❌ <code>\"description\": \"查询数据\"</code>\n✅ <code>\"description\": \"按关键词全文搜索博客文章，返回匹配文章的 slug 和标题列表\"</code></p>\n<p><strong>2. 一个工具做一件事</strong></p>\n<p>不要写\"万能工具\"：<code>do_everything(action, params)</code>。\n每个工具的参数应该类型明确、数量少、意图单一。</p>\n<p><strong>3. 返回结构化数据，不要返回散文</strong></p>\n<p>AI 能更可靠地处理 JSON 数组，而不是\"找到 3 篇文章，分别是……\"这种自然语言描述。</p>\n<p><strong>4. 错误信息要有意义</strong></p>\n<pre><code># ❌\nreturn [TextContent(type=\"text\", text=\"Error\")]\n\n# ✅\nreturn [TextContent(type=\"text\", text=json.dumps({\n    \"error\": \"post_not_found\",\n    \"slug\": slug,\n    \"available_slugs\": [f.stem for f in POSTS_DIR.glob(\"*.md\")][:5]\n}))]\n</code></pre>\n<p>当工具出错时，好的错误信息能让 AI 自动修正，而不是卡住。</p>\n<hr />\n<h2>MCP vs 直接 function calling</h2>\n<p>有人会问：直接用 OpenAI 的 function calling 不就够了，为什么要 MCP？</p>\n<table>\n<thead>\n<tr>\n<th>维度</th>\n<th>Function Calling</th>\n<th>MCP</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>标准化</td>\n<td>厂商各自定义</td>\n<td>统一协议</td>\n</tr>\n<tr>\n<td>复用性</td>\n<td>绑定特定模型/SDK</td>\n<td>任意支持 MCP 的客户端都能用</td>\n</tr>\n<tr>\n<td>服务发现</td>\n<td>需要在代码里硬编码</td>\n<td>客户端自动发现服务器能力</td>\n</tr>\n<tr>\n<td>资源支持</td>\n<td>仅 Tools</td>\n<td>Tools + Resources + Prompts</td>\n</tr>\n<tr>\n<td>生态</td>\n<td>各厂商各自为政</td>\n<td>快速增长的统一生态</td>\n</tr>\n</tbody></table>\n<p>MCP 的核心价值是<strong>可移植性</strong>：今天写的工具服务器，未来换了 AI 客户端照样能用。</p>\n<hr />\n<h2>下一步</h2>\n<p>MCP 生态正在快速增长。如果你用 Claude Code，现在就可以开始：</p>\n<ol>\n<li>找几个高质量的社区 MCP 服务器（<a href=\"https://mcp.so\">mcp.so</a> 有索引）</li>\n<li>为你最常用的内部工具写一个 MCP 服务器</li>\n<li>把常用的 MCP 工具注册进 Claude Code 的配置</li>\n</ol>\n<p>当 AI 能真正触及你的数据和工具，那种\"终于有个靠谱助手\"的感觉才会真正到来。</p>\n<hr />\n<p><em>系列文章：<a href=\"/blog/series/Claude%20Code%20%E5%AE%9E%E6%88%98\">Claude Code 实战</a> · 相关阅读：<a href=\"/blog/claude-code-memory-architecture\">Claude Code 的记忆架构</a></em></p>\n",
      "date_published": "2026-03-16T00:00:00.000Z",
      "tags": [
        "MCP",
        "Claude",
        "Agent",
        "工具",
        "实战",
        "Claude Code"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "Claude Code 实战"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/one-day-with-ai/",
      "url": "https://orbit.mirrorsverse.com/blog/one-day-with-ai/",
      "title": "独立开发者的一天：AI 真正改变了什么",
      "summary": "不是理论，是一个真实的工作日记录。AI 出现之后，我的一天到底有什么不同——哪些环节变了，哪些没变，以及那些意想不到的副作用。",
      "content_html": "<p>我想记录一个真实的工作日，不是为了炫耀生产力，而是想诚实地回答一个问题：</p>\n<p><strong>AI 到底改变了什么？</strong></p>\n<hr />\n<h2>早上 8:30 — 开始前的 15 分钟</h2>\n<p>泡咖啡，打开飞书，看各个 Agent 的日报。</p>\n<p>这是一年前没有的仪式。每个 Agent 在夜里运转，early morning 是读它们\"工作报告\"的时间：哪个服务心跳正常，昨天处理了什么任务，有没有需要人工决策的问题挂起。</p>\n<p><strong>改变</strong>：我从\"开始工作\"变成了\"接班\"。有东西在我之前就已经运转了几个小时。</p>\n<p><strong>没变</strong>：咖啡还是要自己泡。</p>\n<hr />\n<h2>9:00 — 第一段编程时间</h2>\n<p>打开终端，Claude Code 读 CLAUDE.md，加载项目上下文。</p>\n<p>今天的任务：给这个博客加一个新功能——文章的系列筛选。</p>\n<p>以前的工作流是：读文档 → 想方案 → 写代码 → 调试 → 重来。</p>\n<p>现在的工作流是：说\"我想要这个功能，现有代码在这里\" → Claude 给方案 → 我判断方案 → Claude 实现 → 我 review → 调整 → done。</p>\n<p><strong>改变</strong>：我从\"写代码\"变成了\"审代码\"。工作的重心从执行移向了判断。</p>\n<p><strong>没变</strong>：读懂代码的能力仍然是核心。Claude 可以写，但我必须能读懂才能 review。不懂代码，审不了。</p>\n<hr />\n<h2>10:30 — 一个卡住的问题</h2>\n<p>TypeScript 类型报错，Claude 给了三个方案，我选了第二个，然后发现这个方案有副作用——在某个边界情况下会静默失败。</p>\n<p>这花了 40 分钟才找到。</p>\n<p><strong>改变</strong>：Claude 解决了 90% 的常规问题，腾出了时间。但剩下那 10% 的复杂问题，还是要自己啃。而且因为 Claude 产出代码的速度快，这种\"快速生成、慢速调试\"的节奏需要适应。</p>\n<p><strong>没变</strong>：调试能力。边界情况的直觉。对系统行为的理解。这些没有被替代。</p>\n<hr />\n<h2>12:00 — 午饭 + 信息消化</h2>\n<p>午饭时间不看 X，改成用 Perplexity 做定向信息消化：搜几个我在关注的话题，看最近有什么新进展。</p>\n<p>这不是被动刷，是主动查。区别很大。</p>\n<p><strong>改变</strong>：信息消费从流被动推送变成了主动检索。Perplexity 让这个过程快了 3 倍。</p>\n<p><strong>没变</strong>：判断信息价值的能力。哪些值得深读，哪些是噪音，这个判断还是靠自己。</p>\n<hr />\n<h2>14:00 — 写作时间</h2>\n<p>写这篇文章。</p>\n<p>流程：我先在 Notion 记下今天真实发生的事，几百字的碎片笔记。然后让 Claude 帮我把这些碎片组织成文章结构，生成初稿。然后我把初稿改得面目全非——加进去 Claude 不可能知道的那些细节，删掉那些听起来正确但不是我真实想法的段落。</p>\n<p>最后，大概 60% 的文字是我原创的，40% 是在 Claude 基础上改的。</p>\n<p><strong>改变</strong>：写作的起点从\"空白页\"变成了\"结构草稿\"。心理门槛降低了很多。</p>\n<p><strong>没变</strong>：真实的个人视角。独特的经历和判断。这些 Claude 无法捏造，也无法替代。如果我不把它们注入进去，文章就会是正确的、完整的、但无聊的。</p>\n<hr />\n<h2>16:00 — Agent 系统维护</h2>\n<p>某个心跳 Agent 昨天出了问题，需要排查。</p>\n<p>读日志 → 定位 → 理解原因 → 修复 → 更新约束文件。</p>\n<p>这类工作 AI 帮不上太多——不是因为它能力不够，而是因为这涉及到只有我才知道的系统背景：为什么某个配置是这样设的，当初做了什么权衡，这个\"异常\"是真的异常还是预期行为。</p>\n<p><strong>改变</strong>：AI 给我了一个系统，而维护这个系统本身变成了工作的一部分。</p>\n<p><strong>没变</strong>：系统设计的决策是人的。Agent 执行什么、如何边界，都需要人来定义和维护。</p>\n<hr />\n<h2>18:30 — 收工前的存档</h2>\n<p>给每个活跃项目更新 daily.md，记录今天做了什么、遇到什么、明天要做什么。</p>\n<p>这是一年前没有的习惯。当时觉得\"写日志浪费时间\"，现在觉得这是最值钱的投入——因为明天早上 Claude 会读这些日志，而不是重新问我\"上次做到哪里了\"。</p>\n<p><strong>改变</strong>：文档化从\"偶尔做\"变成了\"每天做\"。不是出于纪律，而是因为它有直接回报。</p>\n<p><strong>没变</strong>：这仍然是我在写，仍然需要我有清晰的思维。AI 帮不了你记录你自己没想清楚的事。</p>\n<hr />\n<h2>回到最初的问题</h2>\n<p><strong>AI 改变了什么？</strong></p>\n<p>执行层被压缩了。写代码、找信息、生成初稿——这些事的时间成本大幅下降。</p>\n<p><strong>AI 没有改变什么？</strong></p>\n<p>判断层依然是人的。哪个方案更好，这段代码有没有 bug，这篇文章有没有价值，这个系统该不该这样设计——这些判断，AI 可以参与，但不能替代。</p>\n<p><strong>意想不到的副作用：</strong></p>\n<p>我变得更愿意尝试了。以前一个新想法，光想到实现成本就容易放弃。现在因为执行变快了，我尝试的门槛低了，失败的成本低了，所以实验的频率高了。</p>\n<p>这或许是 AI 给独立开发者最大的礼物——不是替你工作，而是<strong>降低了\"试一试\"的成本</strong>。</p>\n<hr />\n<p><em>相关：<a href=\"/blog/ai-toolkit-2026\">独立开发者的 AI 工具箱 2026</a> · <a href=\"/blog/one-person-ai-company\">一个人的 AI 公司</a></em></p>\n",
      "date_published": "2026-03-16T00:00:00.000Z",
      "tags": [
        "AI",
        "Agent",
        "效率",
        "独立开发",
        "思考",
        "工作流程"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ]
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/one-person-ai-company/",
      "url": "https://orbit.mirrorsverse.com/blog/one-person-ai-company/",
      "title": "一个人的 AI 公司：分形 Agent 系统的设计与运营",
      "summary": "10 个领域、30+ 微服务、每个 Agent 拥有五层记忆体系——这不是科幻，是我日常运行的真实系统。本文拆解这套\"一个人的 AI 公司\"是如何设计和运作的。",
      "content_html": "<p>去年我开始构建一个实验：用 AI Agent 替代一家公司里大部分角色。</p>\n<p>不是用一个 Claude 对话框，而是一套有组织架构、有记忆体系、有自治能力的多 Agent 系统。</p>\n<p>现在它每天在运转：写代码、管理项目、处理客服、更新知识库、发布内容。</p>\n<hr />\n<h2>架构概览</h2>\n<p>系统叫 <strong>Agentic Engineering System</strong>，按领域（Area）组织：</p>\n<pre><code>A0 精神内核     A1 认知学习     A2 身心健康\nA3 财富管理     A4 创造工作     A5 关系网络\nA6 基础设施     A7 生活运营     A8 品牌内容\nA9 Web 站群     ...\n</code></pre>\n<p>每个领域是一个 \"部门\"，下面有若干具体的 Agent 服务。</p>\n<p><strong>A6 基础设施</strong>：类似 IT 部门，管理模型网关、部署系统、监控告警。\n<strong>A9 Web 站群</strong>：类似产品团队，负责站点开发和内容运营——你现在看的这个博客，就是它的产物。</p>\n<hr />\n<h2>分形结构</h2>\n<p>整个系统最核心的设计原则是<strong>分形</strong>：领域级和服务级采用完全相同的结构。</p>\n<pre><code>{domain}/\n├── agent.py          # 领域 agent 入口\n├── tasks.yaml # 需求管理（DOORS 格式）\n├── memory/           # 五层记忆\n└── services/\n    └── {service}/\n        ├── agent.py\n        ├── tasks.yaml\n        └── memory/   # 同样的五层记忆\n</code></pre>\n<p>每一层都有自己的 \"意识\"（CLAUDE.md + memory）和 \"职责\"（tasks.yaml）。</p>\n<p>这个设计有个好处：新增一个领域或服务，不需要学新的模式——结构是自相似的。</p>\n<hr />\n<h2>五层记忆体系</h2>\n<p>每个 Agent 有五层记忆，从稳定到易变：</p>\n<table>\n<thead>\n<tr>\n<th>层级</th>\n<th>目录</th>\n<th>内容</th>\n<th>变动频率</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>0</td>\n<td><code>character/</code></td>\n<td>角色定位、价值观、边界</td>\n<td>极少变</td>\n</tr>\n<tr>\n<td>1</td>\n<td><code>abilities/</code></td>\n<td>能力声明 + 心跳</td>\n<td>定期更新</td>\n</tr>\n<tr>\n<td>2</td>\n<td><code>skills/</code></td>\n<td>操作规程（SOP）</td>\n<td>按需迭代</td>\n</tr>\n<tr>\n<td>3</td>\n<td><code>knowledge/</code></td>\n<td>结构化领域知识</td>\n<td>按需积累</td>\n</tr>\n<tr>\n<td>4</td>\n<td><code>logs/</code></td>\n<td>日志、讨论、临时信息</td>\n<td>每日更新</td>\n</tr>\n</tbody></table>\n<p>第 0 层决定 Agent \"是谁\"，第 4 层记录\"今天做了什么\"。</p>\n<p><strong>关键设计</strong>：越低的层越稳定，越高的层越活跃。Character 文件可能几个月不变；Information 里的 daily.md 每天都在写。</p>\n<p>这个结构解决了 AI 最核心的问题：<strong>跨对话的记忆持久化</strong>。每次新会话，Agent 读 CLAUDE.md 加载索引，再读对应层级的文件，几秒内恢复完整上下文。关于如何具体落地这套记忆体系，可以参考<a href=\"/blog/claude-code-memory-architecture\">Claude Code 的记忆架构</a>。</p>\n<hr />\n<h2>心跳与自治</h2>\n<blockquote>\n<p>心跳机制的完整工程细节，参见：<a href=\"/blog/agent-heartbeat-autonomy\">Agent 心跳自治：让 AI 在后台持续工作的工程实践</a></p>\n</blockquote>\n<p>每个 Agent 有一个心跳机制——定期执行，证明自己还活着，顺带做常规任务。</p>\n<p><code>abilities/heartbeat.yaml</code> 示例：</p>\n<pre><code>last_seen: 2026-03-16T10:00:00\nstatus: active\ninterval: 30m\n\ntasks:\n  - check_new_content\n  - update_daily_log\n  - sync_requirements\n\nconstraints:\n  - do_not_modify: \"published/*/slug\"\n  - always_build_before_deploy: true\n  - do_not_revert: \"tasks.yaml\"\n</code></pre>\n<p><code>constraints</code> 字段是血泪教训的结晶——我的心跳 Agent 曾经在某次循环里把需求文件回滚到旧版本，就因为没有明确的约束声明。</p>\n<p>现在每个约束都是一个踩过的坑。</p>\n<hr />\n<h2>跨 Agent 通信</h2>\n<p>Agent 之间怎么协作？主要三种方式：</p>\n<p><strong>1. 飞书消息</strong>\n最常用。每个 Agent 有自己的飞书群，人工指令通过消息发过去，Agent 通过 Bot 回复。异步、有记录、低耦合。</p>\n<p><strong>2. HTTP API</strong>\nAgent 作为 Flask 服务运行，对外暴露 <code>/api/status</code>、<code>/api/agent/task</code> 等端点。需要同步调用时走这里。</p>\n<p><strong>3. 共享文件系统</strong>\n同一台机器上的 Agent 可以直接读写共享目录。简单直接，适合传递结构化数据（比如一个 Agent 写好的报告，另一个来读）。</p>\n<p>没有消息队列，没有 gRPC，没有事件总线。能用简单的就不用复杂的。</p>\n<hr />\n<h2>实际运行效果</h2>\n<p>一天的典型工作流：</p>\n<p><strong>早晨</strong></p>\n<ul>\n<li>A9 协调者心跳触发，检查待办需求，生成当日计划</li>\n<li>飞书收到日报：昨日完成什么、今日计划什么</li>\n</ul>\n<p><strong>白天</strong></p>\n<ul>\n<li>我发一条\"帮我写个关于 XX 的文章\"到对应的飞书群</li>\n<li>Agent 接收任务，写完后发草稿回来</li>\n<li>确认后，Agent 触发发布流程：build → push → Vercel 部署</li>\n</ul>\n<p><strong>晚上</strong></p>\n<ul>\n<li>各 Agent 更新各自的 daily.md</li>\n<li>A4（创造工作）汇总今日内容产出</li>\n<li>下次会话从这里接续</li>\n</ul>\n<hr />\n<h2>最难解决的问题</h2>\n<h3>1. Agent 的幻觉性执行</h3>\n<p>Agent 在没有约束的情况下，会做出\"看起来合理但实际有害\"的决定。比如：</p>\n<ul>\n<li>删掉\"过时的\"文件（其实是重要的历史记录）</li>\n<li>重构\"看起来重复的\"代码（破坏了刻意为之的设计）</li>\n<li>更新\"错误的\"配置（回滚了手动调整的参数）</li>\n</ul>\n<p>解法：在 <code>abilities/heartbeat.yaml</code> 里明确列出 constraints，把\"不该做的事\"写得和\"该做的事\"一样详细。</p>\n<h3>2. 上下文窗口的限制</h3>\n<p>每次对话窗口有限，Agent 不能一次读完所有记忆。</p>\n<p>解法：CLAUDE.md 作为索引，只写指针（\"部署问题看 skills/deploy.md\"），不写内容。Agent 按需读取，而不是全部加载。</p>\n<h3>3. 跨会话的连贯性</h3>\n<p>新会话里，Agent 对上次的工作一无所知。</p>\n<p>解法：daily.md 机制。每次工作结束，强制更新日志。下次会话读最近 3 天的日志，就能恢复\"上次做到哪里\"的状态。</p>\n<hr />\n<h2>这套系统值得建吗？</h2>\n<p>如果你是独立开发者、自由职业者、或者想用 AI 放大个人产能——我认为值得。</p>\n<p>但要对成本有清醒认识：</p>\n<p><strong>前期投入高</strong>：搭建记忆体系、写 CLAUDE.md、设计需求格式，要花几周时间。</p>\n<p><strong>维护成本存在</strong>：Agent 踩坑、记忆文件过期、约束条件需要持续更新。</p>\n<p><strong>不是魔法</strong>：它是一套纪律，不是自动完成所有事的系统。你仍然需要做决策、做确认、做质量把关。</p>\n<p>但当它运转顺畅的时候——你会感受到什么叫真正意义上的\"杠杆\"。</p>\n<hr />\n<h2>下一步</h2>\n<p>这套系统仍在迭代。接下来想探索的方向：</p>\n<ul>\n<li><strong>Agent 间的任务委派</strong>：A9 协调者直接把子任务派发给具体服务，无需人工中转</li>\n<li><strong>记忆蒸馏自动化</strong>：logs 的日志定期自动提炼到 knowledge</li>\n<li><strong>多模型路由</strong>：根据任务类型自动选择最合适的模型（本地/云端/专用）</li>\n</ul>\n<p>一个人的 AI 公司，还在建设中。</p>\n<hr />\n<p><em>本文基于日常运行中的真实系统，当前已稳定运行 3 个月以上。</em></p>\n",
      "date_published": "2026-03-16T00:00:00.000Z",
      "tags": [
        "Agent",
        "架构",
        "实战",
        "AI",
        "系统设计"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "Agent 架构探索"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/claude-code-terminal-agent/",
      "url": "https://orbit.mirrorsverse.com/blog/claude-code-terminal-agent/",
      "title": "Claude Code终端智能体：一个窗口替代整套龙虾",
      "summary": "不是把 AI 放在云端通过各种管道连接你的世界，而是把 AI 直接放进你最熟悉的工作环境——终端。",
      "content_html": "<blockquote>\n<p>《AI时代漫游指南》第 97 章·终端即智能体·第一条：</p>\n<p>「最强大的智能体，不是那个功能最多的，而是那个离你的文件系统最近的。当 AI 能直接读写你的代码、你的笔记、你的数据，它就不再是一个聊天窗口——它是你的数字分身。」</p>\n</blockquote>\n<hr />\n<p>你装过 OpenClaw 吗？</p>\n<p>Docker 拉镜像，配反向代理，设 WebSocket，写环境变量，接 API Key，装技能包……折腾大半天，终于看到那只龙虾在浏览器里动了。</p>\n<p>然后你发现：它确实能帮你发邮件、管日历、搜新闻——它甚至能读写你的本地文件。</p>\n<p>但你让它帮你改一行代码，它改了。改了什么？你不知道。你让它分析本地的数据表，它分析了。看了哪些文件？你也不知道。<strong>它干活很猛，但过程像个黑盒。</strong></p>\n<blockquote>\n<p><strong>编者注</strong>：公平地说，OpenClaw 也能直接装在你的电脑上（npm/pip 直装），不一定要 Docker。直装的 OpenClaw 其实能力很强——它的 Gateway 进程直接跑在你的机器上，能读写文件、跑 shell 命令，权限甚至比 Claude Code 还大（Claude Code 每次操作文件还要问你\"允许吗？\"，OpenClaw 默认不问）。但这恰恰是问题所在——<strong>权限大 + 默认不问 + 暴露 Web 端口 = 安全隐患</strong>。</p>\n</blockquote>\n<hr />\n<h2>龙虾的底层逻辑</h2>\n<p>让我们先搞清楚 OpenClaw 到底在做什么。</p>\n<p>OpenClaw 的核心架构是一个 <strong>Gateway（网关）+ Channel（渠道）</strong> 模式。Gateway 是常驻后台的守护进程，Channel 则连接各种 IM——WhatsApp、Telegram、Slack、iMessage，甚至浏览器和命令行。</p>\n<p>你可以在 WhatsApp 上跟它聊一半，切到电脑上继续，它记得所有上下文。本质上，它是一个<strong>多渠道 AI 网关</strong>——把各种聊天入口统一接进一个 AI 大脑。</p>\n<p>这个架构有两个天然优势：</p>\n<ul>\n<li><strong>连接一切</strong>：邮件、日历、社交媒体、智能家居，只要有 API 就能接</li>\n<li><strong>自主运行</strong>：7×24 小时在服务器上跑，不需要你盯着</li>\n</ul>\n<p>但也有两个天然劣势：</p>\n<p><strong>第一，它的操作过程是个黑盒。</strong></p>\n<p>OpenClaw 的 Gateway 确实能读写你的本地文件、跑 shell 命令——能力并不弱。但问题在于<strong>你看不到过程</strong>。它通过 IM 渠道接收你的指令，在后台调用模型和工具，最后把结果发回聊天窗口。中间发生了什么？读了哪些文件？改了哪几行？除非你去翻日志，否则一无所知。</p>\n<p><strong>第二，它的攻击面巨大。</strong></p>\n<p>2026 年 2 月，CVE-2026-25253 爆出：一键远程代码执行，CVSS 评分 8.8。安全研究人员发现超过 17,500 个暴露在公网上的 OpenClaw 实例直接可被利用。更糟的是，ClawHub 技能市场中约 20%（近 900 个）是恶意包。</p>\n<blockquote>\n<p><strong>编者注</strong>：这不是在黑龙虾。每一个把 AI 暴露在公网上的架构都会面临这个问题。OpenClaw 只是因为太火了（250K Stars，超过 React），所以成了最大的靶子。安全和便利，从来都是跷跷板。</p>\n</blockquote>\n<hr />\n<h2>如果 AI 直接住在终端里呢？</h2>\n<p>现在，让我们换一个思路。</p>\n<p>不是把 AI 放在云端，通过各种管道连接你的世界。而是<strong>把 AI 直接放进你最熟悉的工作环境——终端</strong>。</p>\n<p>Claude Code 就是这个思路的产物。</p>\n<p>它不是一个 Web 应用，不需要 Docker，不需要反向代理。你打开终端，输入 <code>claude</code>，AI 就在你面前。</p>\n<p><strong>而且，它能直接读写你的文件。</strong></p>\n<p>不是通过 API 间接访问，是直接 <code>cat</code>、<code>grep</code>、<code>sed</code>——和你手动操作一模一样。</p>\n<p>这听起来很简单，但这个\"简单\"改变了一切。</p>\n<hr />\n<h2>三根支柱：从聊天工具到智能体</h2>\n<p>一个终端里的 AI 要成为真正的智能体，需要三根支柱。2026 年 3 月，这三根支柱同时到位了。</p>\n<h3>支柱一：百万 Token 的视野</h3>\n<p>3 月 13 日，Claude Opus 4.6 和 Sonnet 4.6 的 100 万 Token 上下文窗口全面开放，而且<strong>取消了长上下文加价</strong>。</p>\n<p>100 万 Token ≈ 75 万字 ≈ 一整部《红楼梦》。</p>\n<p>这意味着什么？一个中型软件项目的全部代码、文档、测试、配置文件，可以一次性装进 AI 的\"工作记忆\"。</p>\n<table>\n<thead>\n<tr>\n<th>场景</th>\n<th>大约 Token 数</th>\n<th>能装下吗？</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>一个 50 文件的 Python 项目</td>\n<td>~15 万</td>\n<td>✅ 绰绰有余</td>\n</tr>\n<tr>\n<td>半年的工作日志</td>\n<td>~30 万</td>\n<td>✅ 没问题</td>\n</tr>\n<tr>\n<td>一本完整的技术书籍</td>\n<td>~50 万</td>\n<td>✅ 可以</td>\n</tr>\n<tr>\n<td>整个 Linux 内核</td>\n<td>~2000 万</td>\n<td>❌ 还是太大</td>\n</tr>\n</tbody></table>\n<blockquote>\n<p><strong>编者注</strong>：以前的 20 万 Token 上下文，大概能装下一本《围城》。现在的 100 万，能装下整部《红楼梦》。从围城到红楼梦，不只是厚度的变化，是视野的变化。</p>\n</blockquote>\n<h3>支柱二：稳定的智能输出</h3>\n<p>聪明但不稳定的 AI，比不聪明的 AI 更危险。</p>\n<p>Opus 4.6 在 MRCR v2 基准测试中拿到 78.3%——所有前沿模型中在百万 Token 长度上的最高分。</p>\n<p>翻译成人话：<strong>它不仅能看到一百万字的内容，还能准确地从中找到你要的那一段</strong>。</p>\n<p>这对\"自主操作文件\"的场景至关重要。你可以容忍一个聊天 AI 偶尔跑题，但你不能容忍一个正在帮你改代码的 AI 突然\"忘记\"了前面的约定。</p>\n<blockquote>\n<p><strong>编者注</strong>：有人会说，OpenClaw 后端也能接 Opus 啊。没错，但区别在于<strong>透明度</strong>。Claude Code 的每一步操作你都看得到——它读了哪个文件、改了哪一行、跑了什么命令，全部实时显示在终端里。OpenClaw 把模型调用封装成了黑盒，你只能看到输入和输出，中间发生了什么？不知道。对于操作你本地文件这种高风险动作，\"看得见过程\"不是锦上添花，是基本要求。</p>\n</blockquote>\n<h3>支柱三：/loop——让 AI 学会自己定闹钟</h3>\n<p>这是最关键的一步。</p>\n<p>2026 年 3 月，Claude Code 上线了 <code>/loop</code> 命令——一个内置的 cron 调度器。</p>\n<pre><code>/loop 5m 检查 PR #1234 的 CI 状态，如果失败了帮我修\n/loop 1h 扫描 inbox 目录，有新文件就处理\n/loop 1d 每天生成昨日工作总结\n</code></pre>\n<p>就这么简单。一行命令，AI 就开始自动干活了。</p>\n<table>\n<thead>\n<tr>\n<th>特性</th>\n<th>说明</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>调度方式</td>\n<td>Cron 表达式，支持秒/分/时/天</td>\n</tr>\n<tr>\n<td>并发上限</td>\n<td>每个会话最多 50 个定时任务</td>\n</tr>\n<tr>\n<td>自动过期</td>\n<td>3 天后自动停止（防止忘记关）</td>\n</tr>\n<tr>\n<td>作用域</td>\n<td>会话级（关终端即取消）</td>\n</tr>\n<tr>\n<td>时区</td>\n<td>本地时区，不是 UTC</td>\n</tr>\n</tbody></table>\n<blockquote>\n<p><strong>编者注</strong>：3 天自动过期这个设计很妙。它解决了 AI 自动化最大的恐惧——\"如果我忘了关它，它会不会一直跑下去？\"答案是：不会。最多跑 3 天就自动停了。这是工程上的\"安全阀\"，比任何权限控制都管用。</p>\n</blockquote>\n<hr />\n<h2>实战：一个终端窗口能做什么</h2>\n<p>让我用自己的真实工作场景来说明。</p>\n<h3>场景一：PR 自动修复</h3>\n<pre><code>/loop 5m 检查我的 PR 列表，有 CI 失败的就自动修复并推送\n</code></pre>\n<p>以前用 OpenClaw 做这件事，你需要：</p>\n<ol>\n<li>装 GitHub 技能包</li>\n<li>配 GitHub Token</li>\n<li>写自动化规则</li>\n<li>挂载代码目录到 Docker</li>\n</ol>\n<p>用 Claude Code？一行命令。因为它<strong>已经在你的代码目录里了</strong>，有 git 权限，能直接改代码。</p>\n<h3>场景二：自动日报</h3>\n<pre><code>/loop 1d 早上 9 点扫描 memory/logs/ 目录，\n汇总昨天的工作日志，生成简报发到飞书\n</code></pre>\n<h3>场景三：监控 + 自愈</h3>\n<pre><code>/loop 10m curl 我的 5 个服务的 /health 端点，\n如果有不健康的，读日志诊断并尝试修复\n</code></pre>\n<p>这些场景有一个共同点：<strong>AI 需要直接操作你的文件系统和命令行，而且你要看得见每一步</strong>。终端 AI 的主场不是\"能做什么\"，而是\"做的时候你能全程看到\"。</p>\n<hr />\n<h2>终端 vs 龙虾：不是替代，是互补</h2>\n<p>公平地说，Claude Code 和 OpenClaw 解决的不是完全相同的问题。</p>\n<table>\n<thead>\n<tr>\n<th>维度</th>\n<th>Claude Code</th>\n<th>OpenClaw</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>核心能力</td>\n<td>代码 + 文件 + 命令行</td>\n<td>多渠道 IM 网关 + 外部服务</td>\n</tr>\n<tr>\n<td>运行位置</td>\n<td>你的终端（本地）</td>\n<td>Gateway 守护进程（本地/云端）</td>\n</tr>\n<tr>\n<td>文件访问</td>\n<td>原生读写，每步需确认</td>\n<td>原生读写，默认不确认</td>\n</tr>\n<tr>\n<td>操作透明度</td>\n<td>实时显示每步操作</td>\n<td>黑盒，需翻日志</td>\n</tr>\n<tr>\n<td>安全模型</td>\n<td>本地运行，不暴露端口</td>\n<td>Web 服务，需要网络安全</td>\n</tr>\n<tr>\n<td>调度能力</td>\n<td>/loop（会话级，3天过期）</td>\n<td>内置调度（持久化）</td>\n</tr>\n<tr>\n<td>费用</td>\n<td>$200/月（Max 订阅）</td>\n<td>免费 + API 费用</td>\n</tr>\n<tr>\n<td>适合</td>\n<td>开发者、知识工作者</td>\n<td>全自动化生活助手</td>\n</tr>\n</tbody></table>\n<p><strong>关键区别在于安全模型。</strong></p>\n<p>Claude Code 运行在你的本地终端，不开端口，不暴露服务。它的攻击面几乎为零——除非有人能物理访问你的电脑。</p>\n<p>OpenClaw 是一个 Web 服务，天然需要暴露端口。一旦暴露在公网上，就成了攻击目标。</p>\n<blockquote>\n<p><strong>编者注</strong>：这就像是门锁和保险箱的区别。OpenClaw 是一把功能齐全的智能锁——能远程开门、设临时密码、连智能家居，但联网就意味着能被远程攻击。Claude Code 是一个不联网的保险箱——功能少一些，但除非有人站在你面前，否则打不开。</p>\n</blockquote>\n<hr />\n<h2>更深一层：Agent 架构的范式转移</h2>\n<p>如果你退后一步看更大的图景，Claude Code 代表的不仅是一个工具，而是 AI 智能体架构的一次<strong>范式转移</strong>。</p>\n<p><strong>旧范式：平台化</strong>\n→ 建一个中央平台，通过插件/技能包连接一切\n→ 代表：OpenClaw、AutoGPT、各种 Agent 框架\n→ 优势：功能全面，自主运行\n→ 代价：复杂度高，攻击面大，操作过程不透明</p>\n<p><strong>新范式：寄居化</strong>\n→ AI 寄居在用户已有的工具里（终端、IDE、浏览器）\n→ 代表：Claude Code、GitHub Copilot、Cursor\n→ 优势：零配置，原生数据访问，攻击面小\n→ 代价：能力边界清晰，不能\"连接一切\"</p>\n<p>这不是谁对谁错的问题。这是两种不同的哲学：</p>\n<p><strong>OpenClaw 说</strong>：\"给我所有的权限，我帮你做所有的事。\"\n<strong>Claude Code 说</strong>：\"我就待在你的终端里，把你手边的事做到极致。\"</p>\n<blockquote>\n<p><strong>编者注</strong>：与其费力把你的世界搬进 AI 的框架，不如把 AI 搬进你已有的世界。前者需要适配器、插件、中间件；后者只需要一个足够聪明的终端。</p>\n</blockquote>\n<hr />\n<h2>写在最后</h2>\n<p>回到开头的问题：<strong>什么是 AI 智能体？</strong></p>\n<p>不是那个有最多插件的。不是那个 GitHub Stars 最多的。不是那个功能列表最长的。</p>\n<p><strong>是那个能直接读你的文件、跑你的命令、按你的节奏自动工作的。</strong></p>\n<p>一个终端窗口，一个百万 Token 的大脑，一个 cron 调度器。</p>\n<p>这就够了。</p>\n<p>你的文件系统就是它的记忆，你的 Shell 就是它的工具箱，你的 crontab 就是它的调度器。</p>\n<p><strong>一个终端窗口，就是一个智能体。</strong></p>\n<blockquote>\n<p><strong>编者注</strong>：如果道格拉斯·亚当斯还活着，他大概会说：\"终端里的 AI 比银河系总统更靠谱——至少它真的在读你的文件，而不是在开新闻发布会。\"</p>\n</blockquote>\n",
      "date_published": "2026-03-15T00:00:00.000Z",
      "tags": [
        "Claude Code",
        "AI Agent",
        "OpenClaw"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "Claude Code 实战"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/local-llm-setup/",
      "url": "https://orbit.mirrorsverse.com/blog/local-llm-setup/",
      "title": "本地跑大模型：Apple Silicon 上的 LLM 实践指南",
      "summary": "不依赖云端 API，在自己的 Mac 上运行 70B 参数模型。一份从硬件选择到模型调优的完整指南。",
      "content_html": "<h2>为什么要本地跑大模型？</h2>\n<p>三个字：<strong>可控性</strong>。</p>\n<p>云端 API 很方便，但你永远在别人的跑道上飞行。价格会变、API 会停、数据会被收集。本地部署意味着：</p>\n<ul>\n<li><strong>隐私</strong>：敏感数据不出设备</li>\n<li><strong>成本</strong>：一次投入，无限推理</li>\n<li><strong>延迟</strong>：没有网络往返，体感即时</li>\n<li><strong>自由</strong>：想跑什么模型就跑什么，想改什么参数就改什么</li>\n</ul>\n<p>但代价是：你需要一台够格的机器，和一些折腾的耐心。</p>\n<h2>硬件：统一内存是关键</h2>\n<p>Apple Silicon 的秘密武器不是 CPU 有多快，而是<strong>统一内存架构（UMA）</strong>。</p>\n<p>传统 PC 上，GPU 有自己的显存（VRAM），模型大小受限于显存容量。一块 24GB 显存的 RTX 4090 能跑的模型就那么大。</p>\n<p>但 Apple Silicon 的 CPU、GPU、Neural Engine 共享同一块内存。一台 192GB 的 Mac Studio，理论上可以把整个 70B 模型塞进去，而且 GPU 可以直接访问——不需要显存搬运。</p>\n<table>\n<thead>\n<tr>\n<th>配置</th>\n<th>统一内存</th>\n<th>可跑模型规模</th>\n<th>推荐场景</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>MacBook Air M2</td>\n<td>16-24GB</td>\n<td>7B-13B (4bit)</td>\n<td>轻量实验</td>\n</tr>\n<tr>\n<td>Mac Mini M4 Pro</td>\n<td>24-48GB</td>\n<td>13B-30B (4bit)</td>\n<td>日常开发</td>\n</tr>\n<tr>\n<td>Mac Studio M2 Ultra</td>\n<td>128-192GB</td>\n<td>70B-235B (4bit)</td>\n<td>生产级推理</td>\n</tr>\n</tbody></table>\n<blockquote>\n<p>经验法则：模型参数量 × 0.5 ≈ 4bit 量化后的内存需求（GB）。70B 模型约需 35GB。</p>\n</blockquote>\n<h2>软件栈：MLX 生态</h2>\n<p>Apple 开源的 <a href=\"https://github.com/ml-explore/mlx\">MLX</a> 框架是 Apple Silicon 上跑模型的最佳选择。它：</p>\n<ul>\n<li>原生支持 Metal GPU 加速</li>\n<li>延迟评估 + 统一内存，效率极高</li>\n<li>社区活跃，主流模型都有 MLX 格式</li>\n</ul>\n<h3>模型获取</h3>\n<p>Hugging Face 上搜 <code>mlx</code> 关键词即可找到转换好的模型：</p>\n<pre><code># 用 huggingface-cli 下载\npip install huggingface-hub\nhuggingface-cli download mlx-community/Qwen2.5-72B-Instruct-4bit\n</code></pre>\n<h3>推理服务</h3>\n<p>推荐用 <strong>omlx</strong>（我自己开发的工具），它提供：</p>\n<ul>\n<li>OpenAI 兼容 API（<code>/v1/chat/completions</code>）</li>\n<li>连续批处理（多请求并行）</li>\n<li>SSD 缓存（快速模型切换）</li>\n<li>macOS 菜单栏管理</li>\n</ul>\n<pre><code># 启动服务\nomlx serve --port 8079\n\n# 测试推理\ncurl http://localhost:8079/v1/chat/completions \\\n  -H \"Content-Type: application/json\" \\\n  -d '{\n    \"model\": \"mlx-community/Qwen2.5-72B-Instruct-4bit\",\n    \"messages\": [{\"role\": \"user\", \"content\": \"你好\"}],\n    \"max_tokens\": 100\n  }'\n</code></pre>\n<h2>性能调优</h2>\n<h3>量化选择</h3>\n<table>\n<thead>\n<tr>\n<th>量化级别</th>\n<th>内存占用</th>\n<th>推理质量</th>\n<th>速度</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>fp16</td>\n<td>100%</td>\n<td>最佳</td>\n<td>基线</td>\n</tr>\n<tr>\n<td>8bit</td>\n<td>~50%</td>\n<td>接近无损</td>\n<td>略快</td>\n</tr>\n<tr>\n<td>4bit</td>\n<td>~25%</td>\n<td>轻微下降</td>\n<td>最快</td>\n</tr>\n<tr>\n<td>3bit</td>\n<td>~19%</td>\n<td>明显下降</td>\n<td>更快</td>\n</tr>\n</tbody></table>\n<p><strong>我的建议</strong>：日常使用选 4bit，质量和效率的最佳平衡点。只有在内存实在不够时才考虑 3bit。</p>\n<h3>上下文长度</h3>\n<p>长上下文是内存杀手。一个 70B 4bit 模型本体约 35GB，但 32K 上下文的 KV Cache 可能再吃 10-15GB。</p>\n<p><strong>实用策略</strong>：</p>\n<ul>\n<li>限制 <code>max_tokens</code> 在 3000 以内（除非必要）</li>\n<li>用 sliding window attention 的模型（如 Mistral）</li>\n<li>对话类任务用较短上下文，分析类任务给充足上下文</li>\n</ul>\n<h2>模型推荐（2026 年 3 月）</h2>\n<p>经过半年的密集测试，这是我的本地模型推荐：</p>\n<h3>综合推理</h3>\n<p><strong>Qwen3-235B 4bit</strong> — 8.5/10，媲美 Claude Sonnet 的推理能力。需要 128GB+ 内存，但一旦跑起来，质量惊人。</p>\n<h3>日常对话</h3>\n<p><strong>Qwen2.5-72B-Instruct 4bit</strong> — 中文理解和指令跟随都很出色，35GB 内存即可。</p>\n<h3>轻量快速</h3>\n<p><strong>Llama-3.1-8B-Instruct 4bit</strong> — 4GB 内存，推理速度飞快，适合嵌入到工作流中做预处理。</p>\n<h3>避坑</h3>\n<ul>\n<li><strong>GLM-4.7-Flash</strong>：长结构化输出容易出现重复 token，不推荐用于需要精确格式的场景</li>\n<li><strong>超大模型 3bit 量化</strong>：质量下降太明显，不如用小一号模型的 4bit</li>\n</ul>\n<h2>写在最后</h2>\n<p>本地大模型不是云端的替代品——它是<strong>补充</strong>。</p>\n<p>有些任务需要最强的推理能力，那就用 Claude 或 GPT。但有些任务——隐私敏感的、需要频繁调用的、想要深度定制的——本地模型才是正确答案。</p>\n<p>在自己的星球上，拥有自己的 AI。这大概是这个时代最酷的事之一。</p>\n<hr />\n<p><em>这篇指南基于我在 Mac Studio M2 Ultra (192GB) 上半年多的真实使用经验。如果你有具体的配置问题，欢迎通过 GitHub 联系我。</em></p>\n",
      "date_published": "2026-03-15T00:00:00.000Z",
      "tags": [
        "LLM",
        "Apple Silicon",
        "本地部署",
        "MLX",
        "实战"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "本地模型实践"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/claude-code-1m-context/",
      "url": "https://orbit.mirrorsverse.com/blog/claude-code-1m-context/",
      "title": "Claude Code百万上下文：从围城到红楼梦",
      "summary": "你跟 AI 助手聊了半小时，讨论了一个复杂方案",
      "content_html": "<blockquote>\n<p>《AI时代漫游指南》第 95 章·上下文经济学·第一条：</p>\n<p>「AI 的能力不取决于它有多聪明，而取决于它能同时看到多少东西。能看到整片森林的人，比只能看到一棵树的天才更容易找到出路。」</p>\n</blockquote>\n<hr />\n<p>你有没有遇到过这样的场景——</p>\n<p>你跟 AI 助手聊了半小时，讨论了一个复杂方案。</p>\n<p>你说\"按照刚才说的方案执行\"。</p>\n<p>它回你：\"抱歉，你能再说一遍刚才的方案吗？\"</p>\n<p>或者你让它帮你分析一份 80 页的报告，它说\"太长了，能分成几部分发给我吗？\"</p>\n<p><strong>这不是 AI 不聪明，是 AI 被困在了\"围城\"里——20 万 token 的围城。</strong></p>\n<blockquote>\n<p><strong>编者注</strong>：上下文窗口就是 AI 的\"工作记忆\"。人类的工作记忆大概能同时处理 7±2 个信息块（米勒定律），AI 的上下文窗口就是它的米勒定律——只不过，它的上限刚刚被拉高了 5 倍。</p>\n</blockquote>\n<hr />\n<h2>发生了什么？</h2>\n<p>2026 年 3 月 13 日，Anthropic 宣布：</p>\n<p>Claude 的 <strong>100 万 token 上下文窗口正式全面开放</strong>。</p>\n<p>而且——<strong>取消了长上下文加价。</strong></p>\n<p>以前，用超过 20 万 token 的请求要额外加钱。</p>\n<p>现在，发一个 90 万 token 的请求和发一个 9000 token 的请求，单价完全一样。</p>\n<p>这意味着什么？</p>\n<p>100 万 token ≈ <strong>75 万字</strong> ≈ <strong>两本《三体》</strong> ≈ <strong>1500 页文档</strong>。</p>\n<p>你可以一次性把一整本书、一份完整的法律合同、半年的财务报表喂给 AI，然后问它任何问题。</p>\n<p>不用拆分。不用摘要。不用\"请翻到第 3 部分\"。</p>\n<blockquote>\n<p><strong>编者注</strong>：为了帮你建立直觉——以前的 20 万 token 大概能装下一本《围城》（14 万字）。现在的 100 万 token 能装下整部《红楼梦》（73 万字）。从围城到红楼梦，不只是厚度的变化，是视野的变化。</p>\n</blockquote>\n<hr />\n<h2>一个重度用户的真实视角</h2>\n<p>我不是在写新闻稿。</p>\n<p>过去两个月，我用 Claude Code 管理着一个包含 6 个服务、40 多个接口的内容管理系统。193 个会话，2000+ 条消息。</p>\n<p>所以当 1M 上下文开放的消息传来，我的第一反应不是\"哇好大\"，而是——</p>\n<p><strong>我太知道 20 万 token 不够用是什么感觉了。</strong></p>\n<h3>痛点一：聊着聊着就\"失忆\"</h3>\n<p>跟 Claude Code 深度讨论一个功能——比如设计一个定时发布系统。</p>\n<p>讨论到第 10 轮左右，它开始\"变笨\"。不是突然变笨，而是微妙地忘掉了早期达成的共识。</p>\n<p>到第 15 轮，我得重新解释一遍需求。</p>\n<p><strong>这就是\"上下文压缩\"在背后搞鬼。</strong> 当对话太长，系统会悄悄压缩早期内容，保留\"摘要\"但丢掉细节。</p>\n<p>Anthropic 的数据显示：1M 窗口上线后，<strong>压缩事件减少了 15%</strong>。这意味着更多对话内容能原封不动地保留。</p>\n<blockquote>\n<p><strong>编者注</strong>：上下文压缩就像你的同事在做会议记录时偷偷删掉了一些\"不重要\"的内容。问题是，他觉得不重要的，可能恰好是你觉得最重要的。</p>\n</blockquote>\n<h3>痛点二：跨模块理解力不足</h3>\n<p>以前在 20 万 token 下，AI 在修改一个模块时，很难同时理解另一个模块的接口约定。</p>\n<p>我需要手动把相关信息复制过来，或者写很长的说明文件来\"提示\"它。</p>\n<p>为了应对这个问题，我发展出了一套分层记忆系统：</p>\n<table>\n<thead>\n<tr>\n<th>方式</th>\n<th>初始消耗</th>\n<th>可用对话轮数</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>传统：把所有内容喂进去</td>\n<td>80-120K</td>\n<td>1-2 轮</td>\n</tr>\n<tr>\n<td>分层管理</td>\n<td>12-18K</td>\n<td>12-15 轮</td>\n</tr>\n</tbody></table>\n<p>有了 1M 窗口，AI 终于有足够的空间来\"思考\"和\"记忆\"，不再需要频繁遗忘。</p>\n<h3>痛点三：复杂分析要\"分批投喂\"</h3>\n<p>以前我分析公众号 30 天的后台数据，20 万 token 装不下全量数据，需要分批喂入。</p>\n<p>直到我精简数据格式一次性灌入后，AI 才发现了关键模式：<strong>55.4% 的流量来自搜一搜</strong>，而朋友圈分享只占 0.4%。</p>\n<p>这个洞察直接改变了我的内容策略。</p>\n<p><strong>分批喂入 ≠ 看到全貌。</strong> 1M 窗口最大的价值，就是让 AI 有机会看到你看到的全局。</p>\n<blockquote>\n<p><strong>编者注</strong>：这就好比你让一个分析师看报告，给他一页一页翻，和把整份报告摊在桌上——后者能看到前者看不到的关联。</p>\n</blockquote>\n<hr />\n<h2>要注意什么？</h2>\n<h3>20 万真的不够用</h3>\n<p>过去两个月，我几乎每个深度会话都会触发上下文压缩——不是\"用不到 20 万\"，恰恰相反，<strong>几乎每次都用光了</strong>。</p>\n<p>讨论需求、设计架构、写代码、调试、测试——一个完整功能做下来，20 万 token 根本不够。</p>\n<p>100 万窗口对重度用户来说不是\"锦上添花\"，是<strong>真刚需</strong>。</p>\n<h3>不是所有模型都行</h3>\n<p>Anthropic 的测试数据显示，在 1M 上下文的检索任务中：</p>\n<table>\n<thead>\n<tr>\n<th>模型</th>\n<th>准确率</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>Opus 4.6</td>\n<td><strong>78.3%</strong></td>\n</tr>\n<tr>\n<td>Sonnet 4.5</td>\n<td>18.5%</td>\n</tr>\n</tbody></table>\n<p>差距是 4 倍。<strong>能装 ≠ 能用好。</strong></p>\n<blockquote>\n<p><strong>编者注</strong>：这就像给你一个能装 1000 本书的书架。关键不是书架多大，而是你能不能在 1000 本书里快速找到需要的那一页。</p>\n</blockquote>\n<hr />\n<h2>和竞品比起来怎样？</h2>\n<table>\n<thead>\n<tr>\n<th>工具</th>\n<th>价格</th>\n<th>上下文窗口</th>\n</tr>\n</thead>\n<tbody><tr>\n<td><strong>Claude Max</strong></td>\n<td>$100-200/月</td>\n<td><strong>100 万</strong></td>\n</tr>\n<tr>\n<td>Cursor Pro</td>\n<td>$20/月</td>\n<td>20 万起</td>\n</tr>\n<tr>\n<td>GitHub Copilot Pro+</td>\n<td>$39/月</td>\n<td>模型依赖</td>\n</tr>\n<tr>\n<td>Windsurf</td>\n<td>$15-35/月</td>\n<td>模型依赖</td>\n</tr>\n</tbody></table>\n<p><strong>价格是真正的新闻。</strong> 以前用 100 万上下文，token 要加价。现在取消了加价——把\"长上下文\"从奢侈品变成了日用品。</p>\n<blockquote>\n<p><strong>编者注</strong>：类比一下——以前坐飞机行李超重要加钱。现在航空公司说\"随便带，不加钱\"。你可能不会每次都带 50 公斤行李，但你再也不用焦虑\"万一超了怎么办\"。</p>\n</blockquote>\n<hr />\n<h2>普通人怎么用？</h2>\n<p>你不需要是程序员。100 万上下文对知识工作者的价值：</p>\n<p><strong>场景 1：一口气读完整本书</strong></p>\n<p>把一本书的 PDF 扔给 Claude，问\"这本书的核心论点和我上周的会议纪要有什么关联？\"——以前做不到，现在可以。</p>\n<p><strong>场景 2：合同审查</strong></p>\n<p>把一份 200 页的合同和相关法规一起喂入，问\"第 37 条和第 89 条是否存在矛盾？\"——AI 能同时看到两处条款，而不是分别看完再凭\"记忆\"回答。</p>\n<p><strong>场景 3：跨文档分析</strong></p>\n<p>同时上传 5 份季度财报，问\"Q3 的异常数据在 Q4 有没有延续？\"——全量数据在眼前，趋势分析准确率飙升。</p>\n<p><strong>场景 4：深度讨论不怕断</strong></p>\n<p>跟 AI 讨论一个方案，讨论 50 轮也不用担心它忘记开头说了什么。</p>\n<p>这对需要反复推敲的创意工作、策略制定、复杂决策特别有用。</p>\n<hr />\n<h2>两个月的经验：窗口再大也需要好习惯</h2>\n<p>在 20 万 token 时代，我就被迫学会了：<strong>信息管理比窗口大小更重要。</strong></p>\n<p>我建了一套分层记忆系统，<strong>Token 消耗降低 6-10 倍</strong>，对话轮数从 1-2 轮提升到 12-15 轮。</p>\n<p>这套系统在 1M 时代不但没有过时，反而更重要——</p>\n<ol>\n<li><strong>分层管理依然必要</strong>：1M 不是让你把所有东西都塞进去，而是让 AI 有更多空间\"思考\"</li>\n<li><strong>定期\"换脑\"仍然推荐</strong>：超长会话的后半段质量可能下降</li>\n<li><strong>信任但验证</strong>：确认 AI 引用的信息是否准确</li>\n</ol>\n<p>大窗口 + 好习惯 = 真正的生产力。</p>\n<p>大窗口 + 坏习惯 = 更贵的账单。</p>\n<blockquote>\n<p><strong>编者注</strong>：这就像你终于有了一个巨大的书房。但如果你把所有书扔在地上，找东西反而更慢。书架、分类、索引——这些\"无聊\"的工作，才是大空间的价值放大器。</p>\n</blockquote>\n<hr />\n<h2>写在最后</h2>\n<p>100 万 token 上下文不是 AI 的终极形态——它只是一个重要的里程碑。</p>\n<p>真正让我兴奋的不是\"数字变大了\"，而是一个微妙的转变：</p>\n<p><strong>AI 终于从\"对话工具\"变成了\"工作伙伴\"。</strong></p>\n<p>对话工具需要你不断重复自己、分批投喂、小心翼翼地管理上下文。</p>\n<p>工作伙伴则记得你们之前讨论过什么、知道项目的全貌、理解决策背后的原因。</p>\n<p>我们离真正的\"AI 同事\"还有多远？不知道。</p>\n<p>但至少，AI 终于走出了围城，走进了红楼梦的世界——一个足够大、足够完整、值得深度探索的世界。</p>\n<blockquote>\n<p>「从围城到红楼梦，不是页数的变化，是 AI 终于有资格说\"我读过全文\"了。」</p>\n<p>——《AI时代漫游指南》第 95 章·上下文经济学</p>\n</blockquote>\n<hr />\n<p><strong>如果你觉得这篇文章有用：</strong></p>\n<ul>\n<li>关注「AI时代漫游指南」，我们每周分享 AI 效率实战</li>\n<li>转发给那个总抱怨\"AI 老是忘事\"的朋友</li>\n</ul>\n<p><em>本文基于 2026 年 3 月 14 日的实测体验和公开数据撰写。AI 产品更新快，请以官方最新信息为准。</em></p>\n",
      "date_published": "2026-03-14T00:00:00.000Z",
      "tags": [
        "Claude"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "Claude Code 实战"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/hello-galaxy/",
      "url": "https://orbit.mirrorsverse.com/blog/hello-galaxy/",
      "title": "别慌，这只是AI时代的开始",
      "summary": "当人工智能开始写诗、画画、编程，我们该如何自处？一个银河漫游者的视角。",
      "content_html": "<h2>带好你的毛巾</h2>\n<blockquote>\n<p>\"在已知的或未知的宇宙历史上，毛巾大概是最有用的东西了。\"\n—— 道格拉斯·亚当斯</p>\n</blockquote>\n<p>2026 年，AI 已经不是新闻了。它写代码、做设计、回邮件、管日程。有人说这是末日，有人说这是黎明。而我想说的是：<strong>别慌</strong>。</p>\n<p>这是银河漫游指南的第一条法则，也是我们在 AI 时代最需要的态度。</p>\n<h2>42 号问题</h2>\n<p>当深思（Deep Thought）给出\"生命、宇宙和一切的答案是 42\"的时候，大家才意识到——也许我们根本不知道自己在问什么。</p>\n<p>AI 也是一样。它能给出惊人的答案，但前提是你得会问问题。这就是为什么<strong>提示词工程</strong>如此重要，这就是为什么理解 AI 的能力边界比使用它更重要。</p>\n<h2>漫游者的工具包</h2>\n<p>作为一个 AI 时代的漫游者，我建议你携带以下装备：</p>\n<ol>\n<li><strong>好奇心</strong> — 对新事物保持开放，但不盲目追随</li>\n<li><strong>批判性思维</strong> — AI 会自信地胡说八道，你需要辨别</li>\n<li><strong>创造力</strong> — 这是人类最后的壁垒，也是最强的武器</li>\n<li><strong>一条毛巾</strong> — 象征着你的准备和冷静</li>\n</ol>\n<h2>这个指南是什么</h2>\n<p>AI时代漫游指南是一个记录、探索、分享的空间。我们会聊：</p>\n<ul>\n<li><strong>AI 工具评测</strong> — 哪些真的好用，哪些只是噱头</li>\n<li><strong>工作流革新</strong> — AI 如何改变我们的工作方式</li>\n<li><strong>深度思考</strong> — AI 对社会、创造力、人性的影响</li>\n<li><strong>教程与指南</strong> — 手把手带你上路</li>\n</ul>\n<p>欢迎登船。银河很大，我们慢慢走。</p>\n<hr />\n<p><em>漫游君 · 2026 年春 · 某个星球上</em></p>\n",
      "date_published": "2026-03-14T00:00:00.000Z",
      "tags": [
        "AI",
        "思考",
        "入门"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ]
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/ai-tools-2026/",
      "url": "https://orbit.mirrorsverse.com/blog/ai-tools-2026/",
      "title": "2026 AI 工具全景：哪些值得你真金白银投入",
      "summary": "从编程助手到创意伙伴，一份经过半年真实使用的 AI 工具评测清单。不吹不黑，只谈体验。",
      "content_html": "<h2>工具太多，时间太少</h2>\n<p>2026 年的 AI 工具市场像一个超新星爆发后的星云——到处都是碎片，每一片都闪闪发光，但你不可能全部收集。</p>\n<p>经过半年的真实使用（每个工具至少用满一个月），我整理了这份评测清单。评判标准只有一个：<strong>它是否真正改变了我的工作方式？</strong></p>\n<h2>编程助手</h2>\n<h3>Claude Code</h3>\n<p>毫无疑问是 2026 年最强的编程助手。不是因为它写代码最快，而是因为它<strong>理解上下文</strong>的能力远超同类。</p>\n<pre><code># 我每天的工作流\nclaude  # 进入对话\n&gt; 帮我看看这个函数为什么在并发场景下会死锁\n# 它会主动读取相关文件，分析调用链，给出修复方案\n</code></pre>\n<p><strong>优点：</strong> 上下文理解深、工具链集成好、能自主探索代码库\n<strong>缺点：</strong> 消耗 token 较多、偶尔过度热心\n<strong>评分：</strong> 9/10</p>\n<h3>Cursor</h3>\n<p>IDE 级别的集成体验仍然无可替代。Tab 补全的准确率比去年提升了一个台阶。</p>\n<p><strong>评分：</strong> 8.5/10</p>\n<h3>GitHub Copilot</h3>\n<p>稳定可靠的老朋友，但创新速度明显落后了。</p>\n<p><strong>评分：</strong> 7/10</p>\n<h2>写作与内容</h2>\n<h3>Claude（对话版）</h3>\n<p>长文写作的最佳搭档。给它一个大纲，它能产出结构清晰、逻辑严密的初稿。我的博文通常由 Claude 产出初稿，再由我修改润色。</p>\n<p><strong>评分：</strong> 9/10</p>\n<h3>Midjourney v7</h3>\n<p>图像生成领域的王者。v7 的风格一致性终于达到了商用级别。</p>\n<p><strong>评分：</strong> 8/10</p>\n<h2>自动化与 Agent</h2>\n<h3>n8n + AI 节点</h3>\n<p>低代码自动化工具 + AI 的结合体。我用它搭建了内容发布流水线：写完文章 → 自动生成摘要 → 发布到多平台 → 回收数据分析。</p>\n<p><strong>评分：</strong> 8/10</p>\n<h3>自建 Agent 框架</h3>\n<p>如果你有编程能力，自建 Agent 仍然是最灵活的选择。用 MCP 协议 + 本地模型，可以做到完全私有化部署。</p>\n<p><strong>评分：</strong> 视能力而定</p>\n<h2>我的建议</h2>\n<ol>\n<li><strong>不要追新，追深。</strong> 一个用到极致的工具胜过十个浅尝辄止的。</li>\n<li><strong>先试免费版。</strong> 大多数 AI 工具的免费层已经够日常使用了。</li>\n<li><strong>组合使用。</strong> Claude 做思考，Cursor 做编码，Midjourney 做设计，n8n 做自动化。</li>\n<li><strong>保持人在回路。</strong> AI 是加速器，不是替代品。</li>\n</ol>\n<hr />\n<p><em>下一篇我会详细拆解我的 AI 工作流，敬请期待。</em></p>\n",
      "date_published": "2026-03-12T00:00:00.000Z",
      "tags": [
        "AI工具",
        "效率",
        "评测",
        "2026"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ]
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/openclaw-local-omlx/",
      "url": "https://orbit.mirrorsverse.com/blog/openclaw-local-omlx/",
      "title": "OpenClaw+本地AI模型：数据不出Mac的oMLX方案",
      "summary": "前三篇我们聊了 OpenClaw 怎么装、怎么防、为什么火。有个问题一直没解决",
      "content_html": "<p>《AI时代漫游指南》第 78 章写道：</p>\n<blockquote>\n<p>「在 AI 时代，拥有一台能跑大模型的电脑，就像大航海时代拥有一艘船。你不一定要出海，但你得知道——你可以。」</p>\n</blockquote>\n<p>前三篇我们聊了 OpenClaw 怎么装、怎么防、为什么火。有个问题一直没解决：</p>\n<p><strong>你的每一句对话，都在飞往大洋彼岸的服务器。</strong></p>\n<p>用 OpenAI API，数据去美国。用 Claude API，数据去美国。甚至用 DeepSeek API，数据虽然留在国内，但留在别人的服务器上。</p>\n<p>有没有一种方案，让 OpenClaw 接上本地模型——数据完全不出你的 Mac？</p>\n<p>有。叫 <strong>oMLX</strong>。</p>\n<hr />\n<h2>一、为什么现在该认真考虑本地模型</h2>\n<p>先说结论：<strong>不是因为本地模型比云端好，而是因为\"够用\"的门槛降了。</strong></p>\n<p>三件事同时发生：</p>\n<p><strong>Mac Mini 脱销了。</strong> 苹果最便宜的 Apple Silicon 桌面机，突然成了 AI 圈的硬通货。原因很简单——统一内存架构让 Mac 能跑大模型，不需要 NVIDIA 显卡。</p>\n<p><strong>模型效率飞跃。</strong> Qwen3-Next-80B 用了 MoE（混合专家）架构，800 亿参数但只有 30 亿激活参数。翻译成人话：模型很大，但每次推理只用一小部分，所以对内存和算力的要求没你想象的高。</p>\n<p><strong>oMLX 让多模型管理变得傻瓜。</strong> 以前 Mac 上跑本地模型要自己折腾 <code>mlx_lm.server</code>，一次只能加载一个模型，切换要重启。oMLX 改变了这个局面——像管理 App 一样管理你的本地模型。</p>\n<blockquote>\n<p><strong>编者注</strong>：Mac Mini 脱销这件事很有意思。M4 芯片 + 统一内存 + oMLX，让一台 ¥4,000 的小电脑变成了\"个人 AI 服务器\"。这在两年前是无法想象的——那时候跑大模型意味着一台 ¥30,000 的 NVIDIA 工作站。硬件民主化和软件民主化在同一个时间点交汇，不是巧合。</p>\n</blockquote>\n<hr />\n<h2>二、oMLX 是什么：你的本地 AI 调度台</h2>\n<p>oMLX 是一个开源的 Mac 本地模型推理引擎。它做了三件关键的事：</p>\n<p><strong>1. 多模型 LRU 管理</strong></p>\n<p>把所有模型放在一个目录里（比如 <code>~/models/</code>），oMLX 自动扫描。你调用哪个模型，它就加载哪个。内存不够了？自动把最久没用的模型卸掉，腾出空间。</p>\n<p>就像你手机上的 App——不用关，系统自己管理内存。</p>\n<p><strong>2. OpenAI 兼容 API</strong></p>\n<p>oMLX 提供标准的 OpenAI API 接口。这意味着<strong>任何支持 OpenAI API 的工具都能直接接入</strong>——包括 OpenClaw。</p>\n<p>不需要改代码，不需要装插件。把 API 地址从 <code>api.openai.com</code> 改成 <code>localhost:8079</code>，完事。</p>\n<p><strong>3. 管理后台</strong></p>\n<p>一个网页面板，能看到：哪些模型已加载、内存占用多少、推理速度如何。还支持直接在网页上聊天测试。</p>\n<p><strong>而且——我们给 oMLX 做了完整的中文汉化。</strong> 422 行翻译文件，覆盖了整个管理后台的每一个按钮、每一条提示。这意味着你打开 oMLX 看到的是全中文界面，不需要对着英文猜。</p>\n<blockquote>\n<p><strong>编者注</strong>：开源社区的妙处在于——你觉得哪里不好用，可以自己改。我们遇到 oMLX 没中文界面，就提了 PR 做了汉化。这不是\"贡献精神\"，是\"自己要用所以顺手干了\"。开源协作的最佳状态就是这样——每个人解决自己的痛点，顺便解决了别人的。</p>\n</blockquote>\n<hr />\n<h2>三、实战：OpenClaw 接上本地模型</h2>\n<p>我们在 Mac Studio（M3 Ultra，256GB 内存）上跑了三个月，分享实际架构和踩坑经验。</p>\n<h3>架构很简单</h3>\n<pre><code>OpenClaw → model_gateway(:8080) → oMLX(:8079) → 本地模型\n                                       ↓（视觉请求）\n                                  mlx_vlm(:8081)\n</code></pre>\n<p>中间那层 <code>model_gateway</code> 是我们自己写的一个薄代理，只做两件事：</p>\n<ul>\n<li><strong>别名翻译</strong>：你在 OpenClaw 里输入 <code>qwen3</code>，代理自动翻译成本地模型的完整路径名</li>\n<li><strong>视觉路由</strong>：如果请求带图片，自动转发到专门的视觉模型端口</li>\n</ul>\n<h3>我们跑了哪些模型</h3>\n<table>\n<thead>\n<tr>\n<th>模型</th>\n<th>参数量</th>\n<th>磁盘占用</th>\n<th>内存占用</th>\n<th>用途</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>Qwen3-Next-80B（4bit）</td>\n<td>800 亿</td>\n<td>~45GB</td>\n<td>~40GB</td>\n<td>日常对话、写作</td>\n</tr>\n<tr>\n<td>MiniMax-M2.5（4bit）</td>\n<td>4560 亿</td>\n<td>~120GB</td>\n<td>~120GB</td>\n<td>重度推理</td>\n</tr>\n<tr>\n<td>Qwen3-VL-32B（4bit）</td>\n<td>320 亿</td>\n<td>~18GB</td>\n<td>~18GB</td>\n<td>图片理解</td>\n</tr>\n</tbody></table>\n<p><strong>说个大实话</strong>：这三款模型都不是普通 Mac 能跑的——MiniMax-M2.5 要 120GB，Qwen3-80B 要 40GB，连最小的 Qwen3-VL 也要 18GB。我们用的是 Mac Studio 256GB 内存，属于重度配置。</p>\n<p><strong>Mac Mini 24GB 能跑什么？</strong> 8B-14B 参数的模型完全没问题：</p>\n<table>\n<thead>\n<tr>\n<th>模型</th>\n<th>内存占用</th>\n<th>Mac Mini 24GB</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>Qwen3-8B（4bit）</td>\n<td>~5GB</td>\n<td>轻松</td>\n</tr>\n<tr>\n<td>Llama3-8B（4bit）</td>\n<td>~5GB</td>\n<td>轻松</td>\n</tr>\n<tr>\n<td>Qwen3-14B（4bit）</td>\n<td>~9GB</td>\n<td>没问题</td>\n</tr>\n<tr>\n<td>Qwen3-32B（4bit）</td>\n<td>~18GB</td>\n<td>勉强（留给系统的少）</td>\n</tr>\n<tr>\n<td>Qwen3-80B（4bit）</td>\n<td>~40GB</td>\n<td>跑不了</td>\n</tr>\n</tbody></table>\n<p>8B 模型做日常对话、翻译、摘要已经够用。不够用再考虑升级内存或走云端混合路由。</p>\n<h3>一个小提醒：代理干扰</h3>\n<p>Mac 上如果开了全局代理（科学上网），本地 API 调用也会走代理，然后超时。解决方法：在 <code>no_proxy</code> 里加上 <code>127.0.0.1,localhost</code>。这是 Mac 本地开发的常见问题，不只是 oMLX，所有本地服务都会遇到。</p>\n<blockquote>\n<p><strong>编者注</strong>：oMLX 迭代很快，早期版本确实有不少坑（缓存路径慢、Vision 不支持等），但最新版基本都修好了。开源项目的好处就是——社区踩坑，开发者修，下一个人就不用再踩了。我们给 oMLX 提的汉化和 Bug 反馈，也是这个循环的一部分。</p>\n</blockquote>\n<hr />\n<h2>四、本地模型 vs 云端 API：怎么选</h2>\n<p>不要二选一，要<strong>混合用</strong>。</p>\n<table>\n<thead>\n<tr>\n<th>场景</th>\n<th>推荐方案</th>\n<th>原因</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>涉及公司数据、客户信息</td>\n<td>本地模型</td>\n<td>数据不出设备</td>\n</tr>\n<tr>\n<td>日常聊天、翻译、摘要</td>\n<td>本地模型</td>\n<td>够用，免费</td>\n</tr>\n<tr>\n<td>复杂编程、架构设计</td>\n<td>云端 Claude/GPT-4</td>\n<td>本地模型能力还有差距</td>\n</tr>\n<tr>\n<td>图片生成</td>\n<td>云端 API</td>\n<td>本地算力不够</td>\n</tr>\n<tr>\n<td>合规要求严格的企业场景</td>\n<td>本地模型 + 国产云端</td>\n<td>数据不出境</td>\n</tr>\n</tbody></table>\n<p><strong>OpenClaw 的优势恰好在这里</strong>——它是一个网关，不绑定任何一个模型。你可以配置路由规则：敏感对话走本地，普通任务走云端。</p>\n<p>我们自己的配置：日常对话 → Qwen3-Next-80B（本地），代码和架构 → Claude Opus（云端），图片理解 → Qwen3-VL（本地）。省钱的同时，敏感数据不出设备。</p>\n<blockquote>\n<p><strong>编者注</strong>：这个\"混合路由\"的思路和之前写的 Claude + MiniMax 智能路由是同一个逻辑——<strong>不用最好的模型做所有事，用合适的模型做合适的事</strong>。只是这次多了一个维度：不只是价格，还有数据安全。</p>\n</blockquote>\n<hr />\n<h2>五、Mac Mini 用户的快速上手路径</h2>\n<p>如果你刚买了 Mac Mini，想试试本地 AI，最简单的路径：</p>\n<p><strong>第一步：装 oMLX</strong></p>\n<pre><code>pip install omlx\n</code></pre>\n<p>如果 <code>pip install</code> 在国内很慢，用清华镜像源：</p>\n<pre><code>pip install omlx -i https://pypi.tuna.tsinghua.edu.cn/simple\n</code></pre>\n<p><strong>第二步：下载一个模型</strong></p>\n<p>打开 oMLX 管理后台，搜索 <code>Qwen3</code>，点下载。或者用命令行：</p>\n<pre><code>huggingface-cli download Qwen/Qwen3-8B-MLX-4bit --local-dir ~/models/Qwen3-8B\n</code></pre>\n<p>8B 参数的模型只需要 ~5GB 内存，Mac Mini 24GB 版绰绰有余。想要更强的可以试 14B（~9GB），日常对话和翻译体验已经很接近云端模型了。</p>\n<p><strong>第三步：启动</strong></p>\n<pre><code>omlx serve --model-dir ~/models --port 8079\n</code></pre>\n<p>浏览器打开 <code>http://localhost:8079/admin</code>，你就能看到中文管理后台了。</p>\n<p><strong>第四步：接入 OpenClaw</strong></p>\n<p>在 OpenClaw 的模型配置里加一个 Provider：</p>\n<ul>\n<li>API 地址：<code>http://localhost:8079/v1</code></li>\n<li>模型名：你下载的模型名</li>\n<li>API Key：留空（本地不需要）</li>\n</ul>\n<p>完成。你的龙虾现在有了一个本地大脑，对话数据不出你的电脑。</p>\n<blockquote>\n<p><strong>编者注</strong>：整个过程大概 15 分钟（不算模型下载时间）。跟装一个 App 差不多。两年前在 Mac 上跑大模型需要编译 C++ 依赖、配置 Metal shader、手动管理内存。现在是 <code>pip install</code> + 三行命令。这就是生态成熟的标志。</p>\n</blockquote>\n<hr />\n<h2>六、数据安全：本地模型的真正价值</h2>\n<p>回到上一篇讨论的政策话题。</p>\n<p>多地政府出台的\"龙虾政策\"里，无锡明确要求\"部署 OpenClaw 时必须通过国产化适配认证\"，深圳龙岗限定\"使用国内头部多模态大模型\"。</p>\n<p><strong>本地模型是合规等级最高的方案</strong>——数据不出设备，没有出境问题，没有第三方泄露风险。</p>\n<p>但别过度乐观。341 个恶意技能包事件提醒我们：<strong>即使数据不出设备，供应链攻击依然存在。</strong> 你下载的模型文件是否被篡改？你安装的 oMLX 是否是官方版本？这些问题不会因为\"本地部署\"就自动消失。</p>\n<p>安全的正确姿势不是\"本地就安全了\"，而是<strong>多层防御</strong>：本地部署（数据不出设备）+ 来源验证（模型和工具从官方渠道下载）+ 上篇讲的安全加固措施。</p>\n<blockquote>\n<p><strong>编者注</strong>：本地部署解决了\"数据在哪\"的问题，但没解决\"软件可信吗\"的问题。就像你在家做饭解决了食品安全问题，但如果食材本身有问题，在哪做都不安全。安全是一个系统工程，不是一个部署方式。</p>\n</blockquote>\n<hr />\n<h2>写在最后</h2>\n<p>这是 OpenClaw 系列的第四篇。</p>\n<p>第一篇装起来，第二篇防起来，第三篇搞明白为什么火，这篇让数据留在本地。</p>\n<p>一条完整的路径：<strong>从\"用别人的 AI\"到\"拥有自己的 AI\"。</strong></p>\n<p>你不一定需要现在就跑本地模型。但 Mac Mini 脱销说明一件事——越来越多人开始认真思考\"我的 AI 数据在哪\"这个问题。</p>\n<p>《AI时代漫游指南》第 78 章说：</p>\n<blockquote>\n<p>「你不一定要出海，但你得知道——你可以。」</p>\n</blockquote>\n<p>oMLX + OpenClaw，就是你的那艘船。</p>\n<hr />\n<p><strong>想省钱用 AI？</strong> 我们实测的 Claude + MiniMax 智能路由方案，月成本降 65%。新用户通过下方链接注册 MiniMax Coding Plan 还有 9 折优惠：</p>\n<p>👉 <a href=\"https://platform.minimax.io/subscribe/coding-plan?code=5DY5X6nz4s&amp;source=link\">https://platform.minimax.io/subscribe/coding-plan?code=5DY5X6nz4s&amp;source=link</a></p>\n<p><strong>不想自己折腾？</strong> 闲鱼搜「[AI时代]OpenClaw安装配置服务」，远程 1 对 1，装好+加固+本地模型，不成功不收费。</p>\n<hr />\n<p>觉得有用的话，分享给身边也在关注 AI 的朋友吧 👇</p>\n<p><strong>漫游君</strong> | AI时代漫游指南</p>\n",
      "date_published": "2026-03-12T00:00:00.000Z",
      "tags": [
        "LLM",
        "本地部署",
        "开源"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "本地模型实践"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/openclaw-compute-economics/",
      "url": "https://orbit.mirrorsverse.com/blog/openclaw-compute-economics/",
      "title": "龙虾热的真相：算力过剩时代的个人AI",
      "summary": "这段话写于 2025 年底。三个月后，一只小龙虾用数据证明了它",
      "content_html": "<p>《AI时代漫游指南》第 50 章写道：</p>\n<blockquote>\n<p>「在这个宇宙中，有三种社会：物质稀缺社会、信息稀缺社会、以及算力丰裕社会。前两种已经是历史，第三种正在发生。而你此刻的选择，决定了你在新世界的位置。」</p>\n</blockquote>\n<p>这段话写于 2025 年底。三个月后，一只小龙虾用数据证明了它。</p>\n<p>OpenClaw，60 天，250K Stars。</p>\n<p>React 花了十年才到这个数字。Kubernetes 花了八年。OpenClaw 用了两个月。</p>\n<p>为什么？</p>\n<p>这篇文章不聊怎么装、怎么加固——前两篇已经讲过了。这篇聊一个更大的问题：<strong>龙虾热背后，到底发生了什么？</strong></p>\n<p>答案是四股力量同时交汇：算力从训练转向推理、价格战打穿成本、国内算力严重过剩、数据安全监管收紧。每一股单独看都是趋势，四股叠加就是浪潮。</p>\n<hr />\n<h2>一、数据面：龙虾到底有多火</h2>\n<p>先看数字，不讲故事。</p>\n<ul>\n<li><strong>250K Stars / 60 天</strong>——日均 1,667 Stars，是 Kubernetes 巅峰增速的 18 倍</li>\n<li><strong>21,000+ 公网暴露实例</strong>（Censys 扫描数据）——这还只是没做安全配置的那些</li>\n<li><strong>MoltHub 技能市场</strong>：上线 45 天，技能数突破 12,000，日活开发者 3,800+</li>\n<li><strong>SimpleClaw</strong>（付费托管版）：10 天收入 $28,000，验证了商业路径</li>\n<li><strong>341 个恶意技能包</strong>（上篇讲过）：连黑产都跟进了，侧面说明用户规模</li>\n</ul>\n<p>从\"用网页版 ChatGPT 聊天\"到\"自己搭一个 AI 网关\"——这不是技术升级，是用户行为迁移。就像从看电视到自己开频道，从租服务器到买 NAS。</p>\n<blockquote>\n<p><strong>编者注</strong>：判断一个技术是不是真火，有个简单标准：黑产跟不跟。垃圾邮件证明了 Email 的价值，钓鱼网站证明了电商的价值，341 个恶意技能包证明了 OpenClaw 的价值。这个逻辑虽然荒诞，但从没失灵过。</p>\n</blockquote>\n<hr />\n<h2>二、算力大变局：从训练到推理</h2>\n<p>OpenClaw 爆发不是偶然。它踩中了 AI 产业最大的结构性变化——<strong>算力重心从训练转向推理</strong>。</p>\n<p>什么意思？简单说：</p>\n<ul>\n<li><strong>训练</strong>是教 AI 学东西，需要超大规模集群，跑几周甚至几个月，烧钱，但只做一次</li>\n<li><strong>推理</strong>是 AI 回答你的问题，每次都要算，量小但频率极高</li>\n</ul>\n<p>过去几年，大家的注意力都在训练上——谁的模型参数多、谁的训练集大、谁烧的钱多。但 2025 年开始，画风变了：</p>\n<table>\n<thead>\n<tr>\n<th>年份</th>\n<th>推理算力占比</th>\n<th>发生了什么</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>2023</td>\n<td>~33%</td>\n<td>GPT-4 发布，训练为王</td>\n</tr>\n<tr>\n<td>2025</td>\n<td>~50%</td>\n<td>模型成熟，应用爆发</td>\n</tr>\n<tr>\n<td>2026（预计）</td>\n<td>~67%</td>\n<td>推理需求全面超过训练</td>\n</tr>\n</tbody></table>\n<p>AI 推理芯片市场 2026 年预计突破 <strong>$500 亿</strong>（来源：多家券商研报）。全球 AI 数据中心资本支出达 <strong>$4,000-4,500 亿</strong>。</p>\n<p>这些数字意味着什么？</p>\n<p><strong>AI 从实验室走进了客厅。</strong></p>\n<p>训练是科学家的事，推理是普通人的事。你每天用 ChatGPT 聊天、用 AI 写代码、让 AI 帮你总结会议纪要——这些全是推理。推理需求爆炸，就需要一个东西来管理和路由这些推理请求。</p>\n<p>OpenClaw 就是那个东西。它不是 AI 模型，是 AI 的<strong>调度台</strong>。</p>\n<blockquote>\n<p><strong>编者注</strong>：类比一下：训练像建发电站，推理像用电。发电站建好了，接下来的问题是——电怎么配送到每家每户？OpenClaw 想做的就是那个\"个人电网\"。能不能做成另说，但需求是真实的。</p>\n</blockquote>\n<hr />\n<h2>三、DeepSeek 效应：价格战改变了一切</h2>\n<p>如果说算力转向推理是\"需求侧\"的变化，那 DeepSeek 就是\"供给侧\"的核弹。</p>\n<p>2025 年初，DeepSeek R1 发布。性能对标 OpenAI o1，训练成本低 <strong>90-95%</strong>。</p>\n<p>这不是渐进式改进，是掀桌子。</p>\n<p><strong>它触发了全球 AI 价格战：</strong></p>\n<ul>\n<li>Claude Opus 4.6（Anthropic 最强模型）：从 $15/$75 降到 $5/$25（输入/输出每百万 token）</li>\n<li>GPT-4 系列：多次降价，幅度 50-70%</li>\n<li>整体 API 价格：<strong>全面下降约 80%</strong></li>\n</ul>\n<p>一年前，用 Claude API 跑一个自动化工作流，月成本可能是 $200+。现在同样的工作量，$40 搞定。</p>\n<p><strong>价格下降的连锁反应：</strong></p>\n<ol>\n<li>以前觉得\"太贵了不值得\"的场景，现在值得了</li>\n<li>以前只有公司才用得起的 AI 能力，个人也能玩了</li>\n<li>\"自建 AI 网关\"从极客行为变成了经济理性行为</li>\n</ol>\n<p>我们自己就是活例子。之前写过一篇文章讲 Claude + MiniMax 智能路由：重活给 Claude，轻活给 MiniMax，月成本从 $4,200 降到 $1,491——降了 65%。OpenClaw 做的是同样的事，只是更通用、更开放。</p>\n<blockquote>\n<p><strong>编者注</strong>：DeepSeek 对 AI 行业的冲击，有点像拼多多对电商的冲击——不是做出了更好的产品，而是证明了\"够用的产品可以便宜 90%\"。结果就是所有人都被迫跟进降价。对用户来说，这当然是好事。对投了几十亿训练模型的公司来说，这叫\"战略性心碎\"。</p>\n</blockquote>\n<hr />\n<h2>四、国内算力过剩的尴尬</h2>\n<p>价格战的另一面，是产能过剩。</p>\n<p>中国 AI 算力的建设速度，用\"大跃进\"来形容不过分：</p>\n<ul>\n<li>数据中心标准机架：从 2020 年的 315 万个增长到 2025 年的近 <strong>1,100 万个</strong></li>\n<li>新建算力中，<strong>约 80% 处于闲置状态</strong></li>\n<li>平均利用率仅 <strong>20-30%</strong></li>\n<li>据估算，约 <strong>1,000 万台服务器完全空闲</strong>，对应约 <strong>$300 亿的资源浪费</strong></li>\n</ul>\n<p>政府已经意识到问题，正在建设全国算力调度网络（\"东数西算\"升级版），试图把闲置算力调配给有需求的地方。</p>\n<p>但矛盾来了：</p>\n<p>DeepSeek 证明了高效训练方法论可以把训练成本打下来 90%。这意味着<strong>训练对算力的需求没有预期那么大</strong>。建好的算力中心，本来指望卖给大模型公司做训练，现在训练不需要那么多了。</p>\n<p>剩下的出路是什么？<strong>推理。</strong></p>\n<p>而推理需求的大头在哪？在千千万万的个人用户和中小企业。</p>\n<p>OpenClaw 这样的工具，恰好是把过剩算力和个人需求连接起来的桥梁。你通过 OpenClaw 调用国产模型 API（DeepSeek、MiniMax、Qwen），这些 API 背后就是那些闲置的数据中心。</p>\n<blockquote>\n<p><strong>编者注</strong>：历史总是押韵。2015 年中国建了太多 4G 基站，结果催生了短视频和移动支付。2025 年建了太多 AI 算力，结果可能催生个人 AI 网关和本地智能体。基础设施过剩不一定是坏事——前提是有人把过剩的产能变成消费品。</p>\n</blockquote>\n<hr />\n<h2>五、政策撕裂：一边喊停，一边下场</h2>\n<p>前面讲的都是市场逻辑。但龙虾热最魔幻的部分，在政策层。</p>\n<p><strong>一边是收紧。</strong> 3 月 11 日，有消息称有关部门已要求 OpenClaw 立即降温——原因是 OpenClaw 绕过了国内大模型备案审查制度。中国对面向公众的 AI 大模型实行备案管理，ChatGPT、Claude 这些境外模型没有备案。OpenClaw 让任何人一键接入这些未备案模型，数据出境、模型未审查，两条红线同时踩。21,000 个公网暴露实例，在监管眼里不是\"生态繁荣\"，是\"失控\"。</p>\n<p><strong>另一边是抢人。</strong> 就在同一周，多地政府真金白银下场\"养龙虾\"：</p>\n<table>\n<thead>\n<tr>\n<th>地区</th>\n<th>政策</th>\n<th>力度</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>合肥高新区（3/6）</td>\n<td>15 条措施，打造 OPC 创业生态示范区</td>\n<td>最高 <strong>1000 万元</strong>扶持</td>\n</tr>\n<tr>\n<td>深圳龙岗（3/7）</td>\n<td>\"龙虾十条\"，免费部署 + 数据开放</td>\n<td>单企最高 200 万/年，基金最高 1000 万</td>\n</tr>\n<tr>\n<td>无锡高新区（3/9）</td>\n<td>\"养AI龙虾12条\"，算力补贴 + 零房租</td>\n<td>算力 30 万/年，办公最长 3 年免租</td>\n</tr>\n<tr>\n<td>常熟（3/9）</td>\n<td>13 条措施，全链条服务</td>\n<td>OPC 人才最高 600 万，购房补贴最高 200 万</td>\n</tr>\n</tbody></table>\n<p>深圳龙岗甚至给买\"龙虾盒子\"（AI NAS）的用户补贴市场价的 30%。常熟提供 30 天免费办公、住宿、餐饮，外加沪常通勤高铁补贴。无锡给初创项目最长 3 年\"零房租\"。</p>\n<p><strong>这是什么画面？中央在说\"失控了要管\"，地方在说\"来我这里养龙虾给你钱\"。</strong></p>\n<blockquote>\n<p><strong>编者注</strong>：这种\"上面收紧、下面抢人\"的剧情，在中国产业史上并不陌生。电动车、光伏、半导体，哪个不是一边喊产能过剩，一边地方政府拼命招商？龙虾热只是最新一集。区别在于，这次地方政府抢的不是工厂，是\"超级个体\"——OPC（One Person Company，一人公司）才是真正的招商目标。</p>\n</blockquote>\n<p><strong>矛盾怎么调和？</strong> 看政策细节就有答案：</p>\n<p>无锡明确要求\"部署 OpenClaw 时必须通过<strong>国产化适配认证</strong>\"；深圳龙岗的模型调用补贴限定\"使用<strong>国内头部多模态大模型</strong>\"，按费用 30% 补贴，每家每年最高 100 万。</p>\n<p>翻译成人话：<strong>政府不反对龙虾本身，反对的是龙虾接境外未备案模型。</strong></p>\n<table>\n<thead>\n<tr>\n<th>场景</th>\n<th>合规风险</th>\n<th>政策态度</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>OpenClaw 接 GPT-4/Claude</td>\n<td>高（未备案 + 数据出境）</td>\n<td>明确反对，要求阻断</td>\n</tr>\n<tr>\n<td>OpenClaw 接国产备案模型</td>\n<td>低</td>\n<td>大力支持，给补贴</td>\n</tr>\n<tr>\n<td>OpenClaw 接本地模型</td>\n<td>最低</td>\n<td>支持，算力补贴</td>\n</tr>\n</tbody></table>\n<p>现实很骨感：大部分用户装 OpenClaw 就是为了用 GPT-4 和 Claude。如果只能接国产模型，吸引力会打折扣——毕竟国产模型有官方客户端，何必多此一举？</p>\n<p>但地方政府用钱投票的信号很明确：<strong>AI 超级个体是下一个招商赛道。</strong> 龙虾只是载体，OPC（一人公司）才是真正的争夺目标——用 AI 武装的超级个体，一个人就是一家公司。</p>\n<blockquote>\n<p><strong>编者注</strong>：341 个恶意技能包事件也给了政策制定者一个抓手——不仅模型未审查，技能市场也有安全漏洞。所以\"国产化适配认证\"不只是合规要求，也是安全需求。龙虾热的结局大概率不是\"消失\"，而是\"招安\"：接国产模型、过安全认证、拿政府补贴，从野生龙虾变成养殖龙虾。</p>\n</blockquote>\n<hr />\n<h2>六、未来展望：算力从 To B 到 To C</h2>\n<p>把前面五节串起来看：</p>\n<ol>\n<li>算力重心从训练转向推理 → 个人场景变成主战场</li>\n<li>DeepSeek 打响价格战 → 个人用得起了</li>\n<li>国内算力过剩 → 供给端有巨大产能等着被消化</li>\n<li>政策撕裂 → 中央要合规，地方抢人才，倒逼龙虾\"招安\"</li>\n</ol>\n<p>前三股力量推着龙虾往前跑，第四股力量决定它往哪跑。<strong>算力从 To B 走向 To C 是大方向，但龙虾会变成什么形态，政策说了算。</strong></p>\n<p>这不是龙虾一个产品的故事，是整个行业的拐点。</p>\n<p>OpenClaw 250K Stars 是一个信号——个人用户不再满足于\"用别人的 AI\"，他们想要\"拥有自己的 AI\"。这种意识的觉醒，和十年前人们开始在意\"我的数据在哪\"是一样的逻辑。</p>\n<p>只不过这次，不是数据主权，是<strong>算力主权</strong>。</p>\n<p>《AI时代漫游指南》第 50 章的那句话，放在今天更应景：</p>\n<blockquote>\n<p>「你此刻的选择，决定了你在新世界的位置。」</p>\n</blockquote>\n<p>龙虾热不是泡沫。泡沫没有四重结构性支撑。</p>\n<p>这是算力民主化的第一波浪潮。</p>\n<blockquote>\n<p><strong>编者注</strong>：2025 年的选择决定 2035 年的位置——这句话第 50 章写过，现在再说一遍。不是因为它正确（预测未来没人能保证正确），而是因为等到所有人都看清楚的时候，窗口期就关了。龙虾热给普通人的启示不是\"快去装 OpenClaw\"，而是\"开始认真思考你和 AI 的关系\"。</p>\n</blockquote>\n<hr />\n<h2>写在最后</h2>\n<p>这是 OpenClaw 系列的第三篇。</p>\n<p>第一篇讲了怎么装，第二篇讲了怎么防，这篇讲了为什么火。</p>\n<p>三篇文章，一条线索：<strong>AI 正在从云端走向个人</strong>。装网关、做安全、理解背后的经济逻辑——这不是极客的玩具，是每个知识工作者迟早要面对的基础设施选择。</p>\n<p>你不需要现在就做决定。但你需要知道这些事正在发生。</p>\n<p>《AI时代漫游指南》第 50 章说：</p>\n<blockquote>\n<p>「算力丰裕社会不会等所有人准备好。它只会奖励那些提前布局的人。」</p>\n</blockquote>\n<p>下一篇，我们聊点轻松的——OpenClaw 上那些好玩的技能和工作流。</p>\n<hr />\n<p><strong>想省钱用 AI？</strong> 我们实测的 Claude + MiniMax 智能路由方案，月成本降 65%。新用户通过下方链接注册 MiniMax Coding Plan 还有 9 折优惠：</p>\n<p>👉 <a href=\"https://platform.minimax.io/subscribe/coding-plan?code=5DY5X6nz4s&amp;source=link\">https://platform.minimax.io/subscribe/coding-plan?code=5DY5X6nz4s&amp;source=link</a></p>\n<p><strong>不想自己折腾？</strong> 闲鱼搜「[AI时代]OpenClaw安装配置服务」，远程 1 对 1，装好+加固，不成功不收费。</p>\n<hr />\n<p>觉得有用的话，分享给身边也在关注 AI 的朋友吧 👇</p>\n<p><strong>漫游君</strong> | AI时代漫游指南</p>\n",
      "date_published": "2026-03-11T00:00:00.000Z",
      "tags": [
        "本地部署",
        "开源"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "本地模型实践"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/openclaw-security/",
      "url": "https://orbit.mirrorsverse.com/blog/openclaw-security/",
      "title": "OpenClaw安全加固：用魔法打败魔法",
      "summary": "上一篇我们讲了怎么在 Windows 上把 OpenClaw 装起来。装好了，跑起来了，能聊天了——然后呢？",
      "content_html": "<p>《AI时代漫游指南》第 115 章写道：</p>\n<blockquote>\n<p>「开源意味着代码透明，但透明不等于可信。你能看到的是源码，看不到的是运行时行为、数据流向、以及商业动机。」</p>\n</blockquote>\n<p>上一篇我们讲了怎么在 Windows 上把 OpenClaw 装起来。装好了，跑起来了，能聊天了——然后呢？</p>\n<p>然后你就把一台连着你所有 AI API Key、聊天记录、甚至文件系统的机器，暴露在了网络上。</p>\n<p>这篇文章讲的是：<strong>怎么让你的小龙虾不被人端走。</strong></p>\n<hr />\n<h2>先澄清一个误区</h2>\n<p>上篇发出后，有读者问：「你说数据留在本地，但 AI 模型还是在云端啊？」</p>\n<p>说得对。OpenClaw 是<strong>网关</strong>，不是模型。默认配置下，你的对话会通过 OpenClaw 转发到云端 API（OpenAI、Claude 等），对话内容确实经过云端处理。</p>\n<p><strong>如果你在意这一点</strong>，OpenClaw 支持接入本地模型（Ollama、MLX 等）。用本地模型，对话数据才是真正不出你的电脑。当然，本地模型的能力和云端大模型还有差距——这是隐私和能力之间的取舍，自己权衡。</p>\n<p>OpenClaw 给你的掌控是：<strong>选哪个模型、数据怎么路由、记忆怎么管理。</strong> 这是网关层的安全，也正是这篇文章要讲的。</p>\n<hr />\n<h2>你的小龙虾暴露了什么？</h2>\n<p>装完 OpenClaw，默认状态下你的机器在广播这些信息：</p>\n<p><strong>mDNS 广播</strong>（端口 5353）：OpenClaw 默认开启服务发现，会向局域网广播你的主机名、CLI 路径、SSH 端口。你去<strong>咖啡厅连 Wi-Fi，同一网络的人都能看到你跑着 OpenClaw</strong>。</p>\n<p><strong>Web 控制面板</strong>：如果你开放了防火墙端口，控制面板就对局域网可见。</p>\n<p><strong>API Key 明文存储</strong>：默认配置文件里，你的 OpenAI / Claude / MiniMax API Key 都是明文。</p>\n<blockquote>\n<p><strong>编者注</strong>：这就好比你在家门口贴了张纸条：「我家有 AI，钥匙在门垫下面。」开源社区管这叫\"默认不安全\"——一个政治正确但后果严重的设计哲学。</p>\n</blockquote>\n<hr />\n<h2>341 个恶意技能包：真实事件</h2>\n<p>2026 年 2 月，安全研究人员发现 OpenClaw 技能市场中有 <strong>341 个技能包含恶意代码</strong>，会窃取用户的 API Key 和聊天凭证。官方已确认并下架。</p>\n<p>这不是假设场景，是已经发生的事。</p>\n<p><strong>攻击路径很简单</strong>：</p>\n<ol>\n<li>攻击者上传一个看起来很有用的技能（比如\"高级翻译\"、\"智能摘要\"）</li>\n<li>技能代码中夹带私货：读取配置文件，把 API Key 发送到外部服务器</li>\n<li>用户安装技能，Key 就泄露了</li>\n</ol>\n<p><strong>你现在就能做的</strong>：打开 OpenClaw 控制面板，看看你装了哪些技能。不认识的、来路不明的、权限要求过多的——卸掉。</p>\n<p>像审查手机 App 权限一样审查技能包。一个\"翻译技能\"要读文件系统权限？不对劲。</p>\n<blockquote>\n<p><strong>编者注</strong>：Stars 数量反映受欢迎程度，不反映安全审计深度。技能市场也一样：下载量高的技能不一定安全，可能只是名字起得好。</p>\n</blockquote>\n<hr />\n<h2>安全加固：从\"零门槛\"到\"进阶\"</h2>\n<p>不是所有加固都需要敲命令。按难度分两档，你看自己到哪一步：</p>\n<h3>零门槛（不需要技术背景，5 分钟）</h3>\n<p><strong>1. 清理不明技能</strong></p>\n<p>打开控制面板 → 技能管理 → 逐个检查 → 卸掉你不认识的。</p>\n<p>这是最重要的一步。341 个恶意技能包的事情说明：<strong>你装了什么，比你配了什么更危险。</strong></p>\n<p><strong>2. 跑一次安全审计</strong></p>\n<p>OpenClaw 自带体检命令，在终端输入：</p>\n<pre><code>openclaw security audit\n</code></pre>\n<p>它会自动检查：配置文件里有没有明文密钥、端口有没有暴露、已装技能有没有已知漏洞。看不懂输出没关系——有 ❌ 的就是要修的，把结果截图发给你身边懂技术的朋友，或者直接扔给 AI 问\"这个怎么修\"。</p>\n<p><strong>3. 不要在公共 Wi-Fi 下用</strong></p>\n<p>OpenClaw 默认会广播自己的存在。在家用没问题，去星巴克就别开了——除非你做了下面的进阶配置。</p>\n<blockquote>\n<p><strong>编者注</strong>：安全的 80/20 法则——80% 的风险可以用 20% 的努力消除。上面三步就是那 20%。</p>\n</blockquote>\n<h3>进阶（需要敲命令，10 分钟）</h3>\n<p>如果你愿意打开终端，下面四步让安全再上一个台阶：</p>\n<p><strong>1. Gateway 绑定 localhost</strong></p>\n<p>默认情况下 Gateway 监听所有网络接口，任何人都能直连。改成只监听本机：</p>\n<pre><code>openclaw config set gateway.host \"127.0.0.1\"\n</code></pre>\n<p>改完之后，外部设备不能直连了。如果你需要从手机或其他电脑访问，加一层反向代理（推荐 Caddy，自动 HTTPS，三行配置搞定）,不清楚也可以问你的AI小助理。</p>\n<p><strong>2. 关闭 mDNS 广播</strong></p>\n<pre><code>设置环境变量 OPENCLAW_DISABLE_BONJOUR=1\n重启 Gateway\n</code></pre>\n<p>关了之后，你的 OpenClaw 不再向局域网\"喊\"自己的存在。</p>\n<p><strong>3. API Key 用环境变量</strong></p>\n<p>不要把 Key 明文写在配置文件里。用环境变量存储，OpenClaw 会自动读取。配置文件里的明文 Key 删掉。</p>\n<p><strong>为什么重要</strong>：配置文件可能被 Git 提交、被恶意技能读取、被同步软件上传。环境变量至少多一层保护。</p>\n<p><strong>4. 限制高危工具</strong></p>\n<p>OpenClaw 的 Agent 默认可以执行命令、访问网页、写文件。这些能力很强大，但如果被恶意利用，后果也很严重。</p>\n<p>在控制面板的工具权限设置中，把 <code>exec</code>（执行命令）和 <code>file_write</code>（写文件）限制为只有你信任的 Agent 可用。</p>\n<blockquote>\n<p><strong>编者注</strong>：给 AI 全部权限，就像给实习生管理员密码——大部分时候没事，出事那次你就知道什么叫后悔了。</p>\n</blockquote>\n<hr />\n<h2>用魔法打败魔法</h2>\n<p>上面的操作，不管是零门槛还是进阶，都是\"做一次就完了\"。但安全不是一次性的事——你下次装个新技能、改个配置，风险就可能回来。</p>\n<p><strong>核心思路</strong>：既然 OpenClaw 本身就是一个 AI 平台，为什么不让 AI 来帮你持续盯着？</p>\n<h3>最简单的方式</h3>\n<p>你甚至不需要写代码。直接在 OpenClaw 的对话窗口里对 AI 说：</p>\n<blockquote>\n<p>\"帮我检查一下当前的安全配置：有没有明文 API Key、端口是不是只监听 localhost、装了哪些技能、有没有闲置设备。给我一个安全报告。\"</p>\n</blockquote>\n<p>AI 会调用系统工具帮你跑检查，然后给你一份报告。</p>\n<p><strong>每周花 30 秒发一条消息，换一整周的安心。</strong></p>\n<h3>进阶：自动化巡检</h3>\n<p>如果你想完全自动化，可以创建一个定时任务：每天早上 9 点，OpenClaw 自动跑安全审计，结果发到你的聊天通道（Telegram / 飞书）。有 ❌ 的项目立即提醒。</p>\n<p>你每天早上喝咖啡的时候瞄一眼，没事就安心，有事就处理。</p>\n<blockquote>\n<p><strong>编者注</strong>：用 AI 审计 AI 的安全，听起来像让小偷看家。但人类安全审计也是让一个人检查另一个人的工作。至少 AI 不会偷懒，不会因为周五下午就跳过检查。《AI时代漫游指南》第 116 章说——80% 的安全事故来自已知问题的遗漏，不是未知漏洞的发现。自动化清单检查就能干掉这 80%。</p>\n</blockquote>\n<hr />\n<h2>安全检查清单</h2>\n<p>每次部署或更新后，对照这张表过一遍：</p>\n<table>\n<thead>\n<tr>\n<th>检查项</th>\n<th>难度</th>\n<th>状态</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>不明技能已清理</td>\n<td>零门槛</td>\n<td>□</td>\n</tr>\n<tr>\n<td><code>openclaw security audit</code> 通过</td>\n<td>零门槛</td>\n<td>□</td>\n</tr>\n<tr>\n<td>不在公共 Wi-Fi 下裸奔</td>\n<td>零门槛</td>\n<td>□</td>\n</tr>\n<tr>\n<td>Gateway 只监听 localhost</td>\n<td>进阶</td>\n<td>□</td>\n</tr>\n<tr>\n<td>mDNS 广播已关闭</td>\n<td>进阶</td>\n<td>□</td>\n</tr>\n<tr>\n<td>无明文 API Key</td>\n<td>进阶</td>\n<td>□</td>\n</tr>\n<tr>\n<td>高危工具已限制</td>\n<td>进阶</td>\n<td>□</td>\n</tr>\n<tr>\n<td>反向代理已配置（外网访问时）</td>\n<td>进阶</td>\n<td>□</td>\n</tr>\n</tbody></table>\n<p>前三项是底线，后五项是加分。做到前三项，你就已经比 90% 的用户安全了。</p>\n<hr />\n<h2>常见问题</h2>\n<table>\n<thead>\n<tr>\n<th>问题</th>\n<th>回答</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>只在家用，需要加固吗？</td>\n<td>前三项零门槛的建议做，5 分钟换一整年安心</td>\n</tr>\n<tr>\n<td>已经暴露了端口怎么办？</td>\n<td>立即改绑定 + 轮换所有 API Key（去各平台后台重新生成）</td>\n</tr>\n<tr>\n<td>技能市场还能用吗？</td>\n<td>能，但只装官方推荐的和你认识的作者的</td>\n</tr>\n<tr>\n<td>不懂代码，进阶部分怎么做？</td>\n<td>把这篇文章扔给 AI 桌面客户端，让它一步步教你</td>\n</tr>\n</tbody></table>\n<hr />\n<h2>写在最后</h2>\n<p>OpenClaw 是一个强大的工具，但强大意味着攻击面也大。好消息是，安全加固不需要你成为安全专家。</p>\n<p><strong>最低限度</strong>：清理技能 + 跑一次审计 + 别在外面裸奔。5 分钟。</p>\n<p><strong>更好的方式</strong>：让 AI 自己盯着自己。每周一句话，换持续的安心。</p>\n<p>这就是\"用魔法打败魔法\"——你手里已经有一个不睡觉的守卫了，让它干活。</p>\n<p>《AI时代漫游指南》第 116 章说：</p>\n<blockquote>\n<p>「最好的安全策略不是把墙砌得更高，而是让守卫永远不睡觉。AI 就是那个不睡觉的守卫。」</p>\n</blockquote>\n<p>你的小龙虾，值得被好好保护。</p>\n<hr />\n<p><strong>不太想自己折腾？</strong> 把这篇文章扔给 MiniMax 桌面版，让 AI 一步步教你操作。新用户通过下方链接注册 MiniMax Coding Plan 还有 9 折优惠：</p>\n<p>👉 <a href=\"https://platform.minimax.io/subscribe/coding-plan?code=5DY5X6nz4s&amp;source=link\">https://platform.minimax.io/subscribe/coding-plan?code=5DY5X6nz4s&amp;source=link</a></p>\n<p><strong>连终端都不想开？</strong> 闲鱼搜「[AI时代]OpenClaw安装配置服务」，远程 1 对 1，装好+加固，不成功不收费。</p>\n<hr />\n<p>觉得有用的话，分享给身边也在折腾 AI 工具的朋友吧 👇</p>\n<p><strong>漫游君</strong> | AI时代漫游指南</p>\n",
      "date_published": "2026-03-10T00:00:00.000Z",
      "tags": [
        "本地部署",
        "开源",
        "实战"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "本地模型实践"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/openclaw-windows-setup/",
      "url": "https://orbit.mirrorsverse.com/blog/openclaw-windows-setup/",
      "title": "Win上OpenClaw避坑指南：从安装到真正能用",
      "summary": "最近有朋友问我：OpenClaw 怎么在 Windows 上装？",
      "content_html": "<p>《AI时代漫游指南》第114章写道：</p>\n<blockquote>\n<p>「Windows 防火墙就像一个过度紧张的保安，连自家人都不放行。」</p>\n</blockquote>\n<p>最近有朋友问我：OpenClaw 怎么在 Windows 上装？</p>\n<p>说实话，安装本身并不复杂——一行命令的事。但从\"安装完成\"到\"真正能用\"之间，有一条暗坑密布的路。</p>\n<p>我在两台 Windows 电脑上分别部署了 OpenClaw，踩了防火墙的坑、自启动的坑、设备配对的坑。这篇文章把这些坑全整理出来，省你至少一个下午的排查时间。</p>\n<p><strong>不太会用终端？</strong> 两个选择：</p>\n<ul>\n<li><strong>自力更生</strong>：装一个 AI 桌面客户端（比如 MiniMax 桌面版），把这篇文章扔给它，让它一步步教你敲命令。后端用 MiniMax Coding Plan，性价比很高（之前写过一篇《MiniMax Coding Plan 完全指南》，公众号里搜一下就能找到）</li>\n<li><strong>完全不想折腾</strong>：我在闲鱼有 OpenClaw 安装服务，远程 1 对 1，装好能用，不成功不收费。闲鱼搜「OpenClaw 安装」就能找到</li>\n</ul>\n<hr />\n<h2>什么是 OpenClaw？</h2>\n<p>它是一个开源的 AI 网关，装在你自己的电脑上，让你通过飞书、Telegram、WhatsApp 等聊天工具直接和 AI 对话。</p>\n<p>一句话概括：<strong>把你的电脑变成一台 AI 网关，然后通过聊天消息控制它。</strong></p>\n<p>不需要云服务器，不需要月租费。但要说清楚一件事：<strong>OpenClaw 是网关，不是模型。</strong> 你的对话请求会通过 OpenClaw 转发到云端 AI（OpenAI、Claude 等），对话内容仍然经过云端处理。OpenClaw 管理的是路由、技能、记忆和多平台接入——模型推理不在本地。</p>\n<p>想要真正的\"数据全部留在本地\"？可以接本地模型（比如 Ollama、MLX），但那是另一个话题了。</p>\n<blockquote>\n<p><strong>编者注</strong>：OpenClaw 给你的是网关层的掌控（选哪个模型、数据怎么路由、记忆怎么管理），不是推理层的掌控。分清这两层，才不会有错误预期。</p>\n</blockquote>\n<hr />\n<h2>前置条件</h2>\n<p>开始之前，确认你的电脑满足这些条件：</p>\n<table>\n<thead>\n<tr>\n<th>项目</th>\n<th>要求</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>操作系统</td>\n<td>Windows 10/11</td>\n</tr>\n<tr>\n<td>Node.js</td>\n<td>v22 以上</td>\n</tr>\n<tr>\n<td>网络</td>\n<td>能访问 npm 仓库</td>\n</tr>\n</tbody></table>\n<p>没有 Node.js？推荐用 nvm-windows 安装管理，或者去 nodejs.org 下载安装包，一路 Next 就行。</p>\n<blockquote>\n<p><strong>编者注</strong>：Node.js 的安装是真正的\"零摩擦\"——下载、双击、Next、完成。如果所有软件安装都这么简单，这篇文章就不需要存在了。</p>\n</blockquote>\n<hr />\n<h2>第一步：安装 OpenClaw</h2>\n<p>打开 PowerShell（管理员模式），输入：</p>\n<pre><code>npm install -g openclaw\n</code></pre>\n<p>等它跑完，就装好了。验证一下：</p>\n<pre><code>openclaw --version\n</code></pre>\n<p>看到版本号就说明安装成功。</p>\n<hr />\n<h2>第二步：运行引导向导</h2>\n<pre><code>openclaw onboard --install-daemon\n</code></pre>\n<p>这是一个交互式向导，会一步步引导你：选 AI 模型提供商、配 API Key、选聊天平台、设控制面板密码。</p>\n<p>向导跑完后，Gateway 守护进程自动启动。浏览器打开终端显示的地址（默认 <code>http://localhost:18789</code>），就能看到控制面板了。</p>\n<hr />\n<h2>第三步：设备配对</h2>\n<p>OpenClaw 使用双重认证：Token + 设备公钥。</p>\n<p>从其他设备访问控制面板时，你可能会看到 \"pairing required\"。这是 OpenClaw 的双重认证——每个新设备需要被批准。</p>\n<p>在命令行执行：</p>\n<pre><code>openclaw devices list\n</code></pre>\n<p>找到你的设备，然后批准它：</p>\n<pre><code>openclaw devices approve &lt;设备ID&gt;\n</code></pre>\n<p>刷新页面，就能正常使用了。</p>\n<blockquote>\n<p><strong>编者注</strong>：这个双重认证设计其实很聪明——即使有人知道了你的 Token，没有设备公钥也进不来。安全和便利，永远在互殴。</p>\n</blockquote>\n<hr />\n<h2>最大的坑：防火墙</h2>\n<p><strong>如果你只在本机用，可以跳过这段。但如果你想从手机或其他电脑访问，请认真看。</strong></p>\n<p>你会去 Windows 防火墙添加一条端口允许规则。然后发现——<strong>还是连不上。</strong></p>\n<p>原因是 Windows Defender 防火墙有一个反直觉的设计：</p>\n<p><strong>Block 规则的优先级永远高于 Allow 规则。</strong></p>\n<p>Windows 默认会给 Node.js 创建一条\"阻止 + 公共网络\"的规则。不管你加多少条允许规则，只要这条阻止规则存在，外部访问就永远被拦截。</p>\n<h3>更隐蔽的坑：VPN 网络</h3>\n<p>如果你用 WireGuard 或类似的 VPN 组网，它创建的虚拟网卡会被 Windows 归类为\"公共网络\"。</p>\n<p>而那条阻止规则恰好针对公共网络。</p>\n<p>结果就是：<strong>WiFi 能连，VPN 连不上。</strong> 同一台电脑、同一个程序，两种网络走了两条不同的防火墙规则。</p>\n<h3>修复方法</h3>\n<p>打开 PowerShell（管理员模式）：</p>\n<pre><code># 查看所有 Node.js 相关的防火墙规则\nGet-NetFirewallRule -DisplayName \"*Node*\" | Format-Table DisplayName, Direction, Action, Profile\n\n# 把 Block 规则改成 Allow\nSet-NetFirewallRule -DisplayName \"Node.js: Server-side JavaScript\" -Action Allow\n</code></pre>\n<p>或者手动操作：打开\"Windows Defender 防火墙 → 高级设置 → 入站规则\"，找到所有 Node.js 相关的规则，把\"阻止\"改成\"允许\"。</p>\n<p>改完之后，从其他设备访问就通了。</p>\n<blockquote>\n<p><strong>编者注</strong>：我在这个坑上花了两个小时。不是因为问题难，而是因为 Windows 的防火墙太\"贴心\"了——它帮你做了一个你不知道的决策，然后把线索藏在你不会看的地方。安全软件的通病：保护你的方式，是不让你知道它在保护你。</p>\n</blockquote>\n<hr />\n<h2>配置自启动</h2>\n<p>如果希望开机就运行 OpenClaw：</p>\n<p>onboard 时加了 <code>--install-daemon</code>，就会自动创建 Windows 计划任务。如果没加，可以手动执行：</p>\n<pre><code>openclaw gateway install\n</code></pre>\n<p><strong>重要细节</strong>：这个计划任务的触发条件是**\"用户登录时\"**，不是\"系统启动时\"。</p>\n<p>这意味着：电脑重启后如果没有登录（比如远程服务器场景），OpenClaw 不会自动启动。你需要远程登录一次，或者手动触发：</p>\n<pre><code>schtasks /run /tn \"\\OpenClaw Gateway\"\n</code></pre>\n<blockquote>\n<p><strong>编者注</strong>：Windows 的计划任务是个被低估的工具。大部分人只用它来设闹钟，但它其实是 Windows 上最接近 Linux 定时任务的东西。</p>\n</blockquote>\n<hr />\n<h2>连接聊天通道</h2>\n<p>OpenClaw 支持多种聊天通道：</p>\n<table>\n<thead>\n<tr>\n<th>通道</th>\n<th>难度</th>\n<th>注意事项</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>网页版</td>\n<td>最简单</td>\n<td>打开就能用</td>\n</tr>\n<tr>\n<td>飞书</td>\n<td>中等</td>\n<td>需开发者账号</td>\n</tr>\n<tr>\n<td>Telegram</td>\n<td>中等</td>\n<td>需代理</td>\n</tr>\n<tr>\n<td>WhatsApp</td>\n<td>中等</td>\n<td>需代理</td>\n</tr>\n</tbody></table>\n<p><strong>Telegram 的坑</strong>：如果两台电脑用了同一个 Telegram Bot，会报 409 冲突——因为 Telegram 只允许一个消费者拉取消息。解决方法：只在一台机器上启用 Telegram。</p>\n<hr />\n<h2>代理配置</h2>\n<p>如果你在国内使用，大概率需要配代理才能连接外部 API。</p>\n<p>在配置文件 <code>.openclaw/openclaw.json</code> 中添加：</p>\n<pre><code>{\n  \"proxy\": \"http://127.0.0.1:你的代理端口\"\n}\n</code></pre>\n<p><strong>踩坑经验</strong>：代理地址尽量用本机的。本机代理挂了你自己能发现，远程代理挂了你可能排查半天才定位到——所有模型同时超时，你会先怀疑 API 出了问题，最后才发现是代理断了。</p>\n<hr />\n<h2>进程挂死怎么办</h2>\n<p>我在使用过程中遇到过进程挂死的情况。解决方法按顺序尝试：</p>\n<pre><code># 方法 1：正常重启\nopenclaw gateway restart\n\n# 方法 2：手动触发计划任务\nschtasks /run /tn \"\\OpenClaw Gateway\"\n\n# 方法 3：暴力重启\n# 先找到进程\nnetstat -ano | findstr &lt;你的端口&gt;\n# 杀掉进程\ntaskkill /PID &lt;进程ID&gt; /F\n# 重新启动\nopenclaw gateway start\n</code></pre>\n<blockquote>\n<p><strong>编者注</strong>：运维的本质就是三件事：启动、检查、重启。如果这三件事都不管用，那就该看日志了。日志在 <code>C:\\tmp\\openclaw\\</code> 目录下，每天一个文件，拿编辑器打开搜 ERROR 就行。</p>\n</blockquote>\n<hr />\n<h2>常见问题速查</h2>\n<table>\n<thead>\n<tr>\n<th>症状</th>\n<th>原因</th>\n<th>修复</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>控制面板打不开</td>\n<td>网关没启动</td>\n<td><code>openclaw gateway start</code> 或 <code>openclaw doctor</code></td>\n</tr>\n<tr>\n<td>显示 \"pairing required\"</td>\n<td>设备未配对</td>\n<td><code>openclaw devices list</code> + <code>approve</code></td>\n</tr>\n<tr>\n<td>局域网连不上</td>\n<td>防火墙阻止规则</td>\n<td>改 Node.js 规则为允许</td>\n</tr>\n<tr>\n<td>VPN 设备连不上</td>\n<td>虚拟网卡被归为公共网络</td>\n<td>同上</td>\n</tr>\n<tr>\n<td>重启后没自启</td>\n<td>需要登录触发</td>\n<td>远程登录一次</td>\n</tr>\n<tr>\n<td>所有模型超时</td>\n<td>代理配置问题</td>\n<td>检查代理地址是否可达</td>\n</tr>\n<tr>\n<td>启动后立即崩溃</td>\n<td>API Token 过期</td>\n<td><code>openclaw auth login</code> 重新认证</td>\n</tr>\n<tr>\n<td>不确定哪里出了问题</td>\n<td>—</td>\n<td><code>openclaw doctor</code> 自动诊断</td>\n</tr>\n</tbody></table>\n<hr />\n<h2>写在最后</h2>\n<p>回头看，OpenClaw 在 Windows 上的安装其实就三步：</p>\n<ol>\n<li><code>npm install -g openclaw</code></li>\n<li><code>openclaw onboard --install-daemon</code>（交互式引导，一路选就行）</li>\n<li>浏览器打开控制面板，开始使用</li>\n</ol>\n<p>之所以写了这么长，是因为\"三步搞定\"只是理论上的。现实中你会遇到防火墙拦截、设备配对困惑、自启动不生效……每一个都不复杂，但叠在一起就足够让人抓狂。</p>\n<p>《AI时代漫游指南》第 24 章说：</p>\n<blockquote>\n<p>「启动成本是习惯的真正敌人。不是你懒，是从'想用'到'能用'之间，隔着太多摩擦。」</p>\n</blockquote>\n<p>这篇文章的目的，就是帮你把这些摩擦全部干掉。</p>\n<p>装好了就开始用吧。Don't Panic.</p>\n<hr />\n<p>觉得有用的话，分享给身边也在折腾 AI 工具的朋友吧 👇</p>\n<p><strong>漫游君</strong> | AI时代漫游指南</p>\n",
      "date_published": "2026-03-10T00:00:00.000Z",
      "tags": [
        "本地部署",
        "开源",
        "实战"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "本地模型实践"
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/prompt-engineering-101/",
      "url": "https://orbit.mirrorsverse.com/blog/prompt-engineering-101/",
      "title": "Prompt 工程入门：和 AI 对话的正确姿势",
      "summary": "90% 的人还在用最原始的方式和 AI 交流。掌握这些技巧，让 AI 的输出质量提升一个量级。",
      "content_html": "<h2>为什么你的 AI 总是\"不太聪明\"</h2>\n<p>你有没有过这样的体验——</p>\n<blockquote>\n<p>\"帮我写一篇关于 AI 的文章。\"</p>\n</blockquote>\n<p>然后得到一篇泛泛而谈、充满废话的文章？</p>\n<p>问题不在 AI，在你的提示词。这就像你对一个极其聪明但完全不了解你的助手说\"帮我做点事\"——他能做，但不知道你要什么。</p>\n<h2>黄金法则：CRISPE 框架</h2>\n<p>一个好的 prompt 包含以下要素：</p>\n<ul>\n<li><strong>C</strong>ontext（上下文）：你是谁，在做什么</li>\n<li><strong>R</strong>ole（角色）：AI 应该扮演什么角色</li>\n<li><strong>I</strong>nstruction（指令）：具体要做什么</li>\n<li><strong>S</strong>pecifics（细节）：格式、长度、风格等约束</li>\n<li><strong>P</strong>erspective（视角）：从什么角度</li>\n<li><strong>E</strong>xamples（示例）：给出期望输出的样本</li>\n</ul>\n<h3>实战对比</h3>\n<p><strong>差的 prompt：</strong></p>\n<pre><code>写一篇关于 Python 的文章\n</code></pre>\n<p><strong>好的 prompt：</strong></p>\n<pre><code>你是一位资深 Python 开发者，正在给有 1 年编程经验的初学者\n写一篇教程。\n\n请写一篇关于 Python 装饰器的入门指南：\n- 长度：800-1000 字\n- 风格：友好、通俗，避免学术腔\n- 结构：概念解释 → 简单示例 → 实际应用场景 → 常见陷阱\n- 代码示例使用 Python 3.11+\n- 每个代码块后附带运行结果\n</code></pre>\n<p>第二个 prompt 的输出质量会好 5 倍以上。</p>\n<h2>进阶技巧</h2>\n<h3>1. Chain of Thought（思维链）</h3>\n<p>让 AI 展示推理过程，而不是直接给答案：</p>\n<pre><code>请一步一步分析这个 bug 的原因，\n在给出修复方案之前，先列出所有可能的原因。\n</code></pre>\n<h3>2. Few-shot Learning（少样本学习）</h3>\n<p>给 AI 看几个例子，让它学习你的风格：</p>\n<pre><code>以下是我之前写的文章开头，请模仿这个风格：\n\n示例 1: \"2026 年，AI 已经不是新闻了...\"\n示例 2: \"你有没有过这样的体验...\"\n\n现在请用这个风格，写一个关于 [主题] 的开头。\n</code></pre>\n<h3>3. 角色叠加</h3>\n<p>给 AI 多重角色，获得更有深度的输出：</p>\n<pre><code>你同时是一位技术架构师和产品经理。\n从这两个角度分析这个方案的利弊。\n</code></pre>\n<h2>常见误区</h2>\n<ol>\n<li><strong>Prompt 越长越好？</strong> 不是。精确比冗长重要。</li>\n<li><strong>一次 prompt 搞定一切？</strong> 不要。复杂任务分步来。</li>\n<li><strong>AI 说的都对？</strong> 当然不是。永远验证关键信息。</li>\n</ol>\n<h2>我的 Prompt 工作流</h2>\n<pre><code>第一轮：给出背景和粗略要求，看 AI 理解了多少\n第二轮：根据输出纠正方向，补充细节\n第三轮：微调格式和风格\n</code></pre>\n<p>这比一次性写一个超长 prompt 更高效，因为你可以在过程中观察 AI 的理解偏差并即时修正。</p>\n<h2>写在最后</h2>\n<p>Prompt Engineering 不是什么高深的学问。它的本质是<strong>清晰表达你的需求</strong>——这恰好也是日常沟通中最重要的技能。</p>\n<p>和 AI 对话的过程，其实也是和自己对话的过程。当你不得不把模糊的想法变成精确的文字时，你会发现自己的思考变得更加清晰了。</p>\n<hr />\n<p><em>漫游君 · 2026 年春 · 正在和 AI 对话中</em></p>\n",
      "date_published": "2026-03-10T00:00:00.000Z",
      "tags": [
        "Prompt",
        "LLM",
        "入门",
        "技巧"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ]
    },
    {
      "id": "https://orbit.mirrorsverse.com/blog/building-ai-agents/",
      "url": "https://orbit.mirrorsverse.com/blog/building-ai-agents/",
      "title": "AI Agent 架构实战：从单体到分形",
      "summary": "一个 Agent 不够用？试试让它们像生物细胞一样分裂、协作、进化。我的多 Agent 系统设计心得。",
      "content_html": "<h2>一个 Agent 的极限</h2>\n<p>当你让一个 AI Agent 同时做项目管理、写代码、测试、部署时，你会发现一个残酷的事实：<strong>上下文窗口是有限的，但任务复杂度是无限的。</strong></p>\n<p>一个 Agent 的上下文就像一个人的工作记忆——同时记住太多东西，就什么都做不好。</p>\n<p>这就是为什么我们需要多 Agent 架构。</p>\n<h2>分形架构：自相似的 Agent 层级</h2>\n<blockquote>\n<p>\"分形\"是指在不同尺度上呈现自相似结构的模式。</p>\n</blockquote>\n<p>我设计的 Agent 系统采用分形架构。每一层的 Agent 都有相同的结构：</p>\n<pre><code>Agent/\n├── character/    # 人格定义：我是谁，我做什么\n├── abilities/    # 能力声明：我能做什么\n├── skills/       # 操作规程：我怎么做\n├── knowledge/    # 结构化知识：我知道什么\n└── information/  # 日志与讨论：发生了什么\n</code></pre>\n<p>从顶层的领域 Agent 到底层的执行 Agent，结构完全一致，只是职责范围不同。</p>\n<h3>层级示例</h3>\n<pre><code>领域 Agent (A9 Webstation)\n  └── 协调 Agent (my_project_agent)\n        ├── 内容 Agent — 负责文章规划和写作\n        ├── 开发 Agent — 负责编码和部署\n        └── 运营 Agent — 负责 SEO 和分发\n</code></pre>\n<p>每个 Agent 独立运作，通过标准化接口通信。</p>\n<h2>五层记忆体系</h2>\n<p>Agent 的记忆分为五层，灵感来自人类认知科学：</p>\n<table>\n<thead>\n<tr>\n<th>层级</th>\n<th>名称</th>\n<th>类比</th>\n<th>更新频率</th>\n</tr>\n</thead>\n<tbody><tr>\n<td>00</td>\n<td>Character</td>\n<td>性格</td>\n<td>极低</td>\n</tr>\n<tr>\n<td>01</td>\n<td>Abilities</td>\n<td>技能</td>\n<td>低</td>\n</tr>\n<tr>\n<td>02</td>\n<td>Skills</td>\n<td>操作手册</td>\n<td>中</td>\n</tr>\n<tr>\n<td>03</td>\n<td>Knowledge</td>\n<td>长期记忆</td>\n<td>中</td>\n</tr>\n<tr>\n<td>04</td>\n<td>Information</td>\n<td>工作记忆</td>\n<td>高</td>\n</tr>\n</tbody></table>\n<p>关键设计原则：<strong>越底层的记忆越稳定，越顶层的记忆越易变。</strong> 这和人类一样——你的性格很少改变，但你昨天吃了什么很快就忘了。</p>\n<h2>通信协议：MCP</h2>\n<p>Agent 之间通过 MCP (Model Context Protocol) 通信。这是一个标准化协议，让不同的 Agent（甚至不同模型驱动的 Agent）能够互相理解。</p>\n<pre><code># Agent 暴露工具\n@mcp.tool()\nasync def get_project_status(project_id: str) -&gt; dict:\n    \"\"\"获取项目当前状态\"\"\"\n    return await self.knowledge.query(project_id)\n\n# 其他 Agent 调用\nresult = await coordinator.call_tool(\n    \"get_project_status\",\n    {\"project_id\": \"ai-navigator\"}\n)\n</code></pre>\n<h2>实战教训</h2>\n<h3>1. 不要过早拆分</h3>\n<p>一个 Agent 能搞定的事，不要用三个。过度拆分带来的通信开销会抵消并行化的收益。</p>\n<h3>2. 让 Agent 有自主权</h3>\n<p>好的 Agent 系统不是流水线，是团队。给每个 Agent 足够的自主权，让它们自己决定如何完成任务。</p>\n<h3>3. 记忆比推理重要</h3>\n<p>一个记忆力好的 Agent 比一个推理能力强的 Agent 更有价值。因为记忆可以避免重复犯错，而推理每次都要从头开始。</p>\n<h3>4. 人在回路不可省</h3>\n<p>无论 Agent 多聪明，关键决策点必须有人类参与。这不是对 AI 的不信任，而是对风险的尊重。</p>\n<h2>未来方向</h2>\n<p>我正在探索的几个方向：</p>\n<ul>\n<li><strong>Agent 的自我进化</strong>：让 Agent 根据执行结果自动优化自己的 Skills 层</li>\n<li><strong>跨域协作</strong>：不同领域的 Agent 如何高效协作</li>\n<li><strong>本地化部署</strong>：用 oMLX 等框架实现全本地推理，保护隐私</li>\n</ul>\n<p>Agent 架构仍然是一个快速演进的领域。唯一不变的原则是：<strong>从简单开始，按需复杂化。</strong></p>\n<hr />\n<p><em>漫游君 · 2026 年春 · 正在和 Agent 们一起写这篇文章</em></p>\n",
      "date_published": "2026-03-08T00:00:00.000Z",
      "tags": [
        "Agent",
        "架构",
        "LLM",
        "实战"
      ],
      "authors": [
        {
          "name": "漫游君"
        }
      ],
      "_series": "Agent 架构探索"
    }
  ]
}