AI Agent on KnightLi的博客

OpenAI Symphony 是什么？Codex 编排、Issue 驱动与 AI Agent 开发工作流

Mon, 25 May 2026 00:17:32 +0800

OpenAI 最近开源了一个很有意思的 Codex 编排规范：Symphony。

它不是另一个聊天式编程助手，也不是一个完整的新 IDE。更准确地说，Symphony 是一套面向 Codex 的“工作编排方式”：把类似 Linear 的 issue tracker 变成编程智能体的控制平面，让每一个未关闭的任务都能对应一个持续运行的 Agent。

官方文章里有一句话很能概括它的方向：过去工程师要同时盯着多个 Codex 会话，不断分配任务、审查输出、纠偏和重启；Symphony 想解决的，正是这个上下文切换瓶颈。

Symphony 解决的不是写代码，而是管理 Agent

单个 Codex 会话适合交互式开发：你给它一个任务，它修改代码，你 review，再继续追问。但当团队开始同时使用多个 Agent 时，问题会从“代码能不能写出来”变成“谁在做哪件事、做到哪一步、失败后谁来接手”。

OpenAI 的做法是把工作重心从“会话”切到“任务”：

issue 是真正的工作单元；
每个未关闭 issue 都可以映射到一个独立 Agent 工作空间；
Symphony 负责持续轮询任务看板，决定哪些任务需要启动、重试、停止或回收；
Codex 在工作空间里执行实现、测试、提交、创建 PR、更新状态等动作；
人类不再微操每个会话，而是审查结果、调整目标和维护边界。

这背后的变化很关键：Agent 不再只是一个被人类临时唤起的工具，而是开发流程里持续运行的一类执行者。

为什么是 issue tracker？

因为团队已经用 issue tracker 管理真实工作。

需求、bug、重构、迁移、调研、优先级、阻塞关系、负责人、里程碑，这些信息本来就沉淀在 Linear、GitHub Issues 或类似系统里。Symphony 没有重新发明一个庞大的控制台，而是把这些现有系统当作 Agent 的任务入口。

这样做有几个好处：

工作不必从 issue 复制到聊天窗口里。
人类可以继续按熟悉的方式创建、拆分、排期和关闭任务。
Agent 的状态变化能回写到同一个工作系统里，方便团队异步协作。
任务依赖可以自然形成 DAG，让未阻塞的任务并行推进。

如果把传统 CI 看成“代码提交后的自动化”，Symphony 更像是“issue 创建后的自动化”。

它的核心工作流

一个典型的 Symphony 流程可以理解为：

创建 issue
  -> Symphony 轮询到可执行任务
  -> 为该 issue 创建独立 workspace
  -> 启动 Codex agent session
  -> Agent 阅读任务、修改代码、运行测试
  -> 创建或更新 PR
  -> 写回任务状态、评论、证据和交付物
  -> 人类 review、合并或要求修改

官方规范里还强调了几个工程化点：

每个 issue 使用独立工作空间，降低相互污染；
编排器维护重试、并发和恢复状态；
工作流策略放在仓库内的 WORKFLOW.md，让团队把 Agent 应该如何处理任务写成可版本化的规则；
实现需要保留可观测性，至少要有结构化日志；
成功状态不一定是 Done，也可以是交给人类 review 的中间状态。

这说明 Symphony 不是简单地“让 AI 自动写代码”，而是在定义一套可运行、可恢复、可审计的 Agent 工作系统。

目标驱动，而不是死板状态机

OpenAI 在文章里提到一个重要转变：早期他们尝试把很多动作写死在外层 harness 里，例如提交代码、跑测试、处理 GitHub 流程。但随着 Codex 能力增强，这种方式反而限制了 Agent。

后来的方向是给 Agent 设定目标，而不是把每一步都写成固定状态转换。

比如，一个任务的目标可以是“完成 Vite 迁移并确保 CI 通过”。Agent 可以自己判断是否需要改配置、修测试、读 CI 日志、处理 review feedback，甚至拆出新的后续 issue。Symphony 负责提供边界、上下文和运行框架，而不是替 Agent 规定每一个动作。

这也是它和传统自动化脚本的区别：脚本擅长重复确定流程；Symphony 面向的是带有不确定性的工程任务。

和普通 Codex 使用方式有什么不同？

普通 Codex 会话更像“人带着 AI 写代码”：

人类打开会话；
人类描述任务；
人类观察输出；
人类随时纠偏；
任务结束后再开下一个会话。

Symphony 更像“团队把任务池交给一组 Agent 执行”：

人类写清楚 issue；
系统持续发现可执行任务；
Agent 在独立环境里推进；
结果以 PR、评论、测试状态、视频或分析报告的形式返回；
人类在关键节点做 review。

这不是替代工程师，而是把工程师从“同时照看多个会话”的负担里解放出来。OpenAI 在官方文章中提到，在部分团队中，合并到主分支的 PR 数量有明显提升；但更值得注意的是工作方式的变化：试验一个想法、发起一次重构、验证一个假设的启动成本变低了。

适合哪些场景？

Symphony 更适合这些任务：

常规功能实现；
已有代码库里的小型重构；
基础设施迁移；
依赖升级；
测试补齐；
CI 修复；
调研后生成实现计划；
根据 review feedback 继续修改 PR。

它不一定适合高度模糊、需要强业务判断或架构拍板的任务。对这类问题，交互式 Codex 会话仍然更自然，因为人类需要在过程中持续参与。

风险和边界

Symphony 的吸引力很强，但真正落地时不能只看“自动化”这一面。

几个边界要提前想清楚：

issue 必须写清楚，否则 Agent 会把模糊需求放大成错误实现；
Agent 的权限要收敛，尤其是仓库、密钥、生产环境和第三方服务访问；
每个工作空间要隔离，避免多个任务相互污染；
CI、测试、lint 和 review 仍然是必须的质量门；
任务状态、PR 链接、日志和失败原因要可追踪；
人类 review 不能省，尤其是涉及安全、计费、数据迁移和权限逻辑的改动。

官方仓库也把 Symphony 定位为 trusted environment 里的工程预览和参考实现，而不是一个拿来就能无脑替代研发流程的成品平台。

我对 Symphony 的理解

Symphony 最有价值的地方，不在于它用了 Linear，也不在于参考实现选择了 Elixir，而在于它重新定义了编程 Agent 的入口。

过去我们习惯从聊天窗口启动 AI 编程：这很灵活，但规模一大，人类注意力就成了瓶颈。Symphony 把入口放回 issue tracker，让 Agent 围绕真实任务持续工作。这样一来，AI 编程从“个人效率工具”开始向“团队工作流基础设施”靠近。

如果你已经在使用 Codex、Claude Code、Cursor Agent 或类似工具，Symphony 值得关注的不是某个具体实现，而是它背后的模式：

不要只管理 Agent 会话，要管理需要完成的工作。

这可能会成为下一阶段 AI 编程工具的关键分水岭。

参考链接

browser-harness 的 domain skills 机制：让 AI Agent 不再重复踩网页自动化的坑

Sun, 24 May 2026 23:43:35 +0800

browser-use/browser-harness 最有意思的地方，不只是让 AI Agent 能控制真实 Chrome，而是它把网页操作中的经验变成了可以复用的 domain skills。

这件事很关键。浏览器自动化真正困难的地方，往往不是“能不能点击按钮”，而是每个网站都有自己的细节：

哪些页面必须登录。
哪些数据可以直接走 API。
哪些按钮用普通 DOM 点击无效。
哪些 iframe、shadow DOM、弹窗会挡住流程。
哪些选择器稳定，哪些只是临时 class。
哪些操作涉及账号、支付或不可逆变更，必须让人确认。

如果这些经验只留在一次任务日志里，Agent 下次还会重新踩坑。domain skills 的作用，就是把这些经验沉淀下来，让 Agent 不必每次都像第一次打开网站。

domain skills 是什么

可以把 domain skills 理解成“给 Agent 看的站点操作手册”。

它不是普通的用户文档，也不是一次性脚本。它更像一组经过实测的站点级知识：

这个站点适不适合用浏览器。
如果有 API，应该优先用哪个 API。
如果必须操作网页，应该从哪个 URL 进入。
哪些 DOM 结构、aria-label、按钮行为经过验证。
哪些常见写法会失败。
哪些场景要停止并请求人类介入。

这类内容既能被人类审查，也能被 Agent 在任务中读取。它把“临场摸索”变成“可维护经验”。

它不是让 Agent 盲目点击

一个好的浏览器 Agent，不应该把所有问题都变成打开网页、看截图、点按钮。

domain skills 里很重要的一类经验，恰恰是在告诉 Agent：什么时候不要用浏览器。

比如 ArXiv 这类站点，论文搜索、元数据和摘要可以通过 Atom API 或 HTML meta 标签直接拿到。用 HTTP 请求通常比打开浏览器更快、更稳，也更容易解析。

GitHub 也是类似思路。仓库、用户、release 数据优先用 REST API；文件内容优先读 raw.githubusercontent.com；只有 GitHub Trending 这类没有等价 API 的页面，才需要进入浏览器。

这说明 browser-harness 的思路不是“浏览器万能”，而是把浏览器放在正确位置：当 API、HTTP、静态页面无法解决问题时，再让 Agent 操作真实页面。

它记录的是站点级知识

传统自动化脚本通常围绕一次任务写，比如：

`1`	`打开页面 -> 输入关键词 -> 点击按钮 -> 下载文件`

这种脚本可以完成任务，但经验很容易散落在代码里。站点一改版，脚本失效；换一个任务，很多经验也没法复用。

domain skills 的粒度更接近站点级知识库。它关心的是：

Amazon 搜索结果里哪个容器选择器稳定。
GitHub 哪些数据应该走 REST API。
LinkedIn 邀请管理页的按钮 aria-label 有什么差异。
Shopify Admin 里哪些页面是嵌入式 app。
Shopify Polaris 输入框为什么不能只用普通 JS 设置 value。
Browser Use Cloud 的浏览器实例如何创建、列出和清理。

这些经验不是一次任务的步骤，而是以后很多任务都会用到的判断依据。

例子：Amazon 商品搜索

Amazon 商品搜索的经验，重点不只是“怎么搜索商品”，而是哪些路径更稳定。

比较可靠的做法是直接使用搜索 URL，而不是每次都打开首页再模拟输入。搜索结果可以从 [data-component-type="s-search-result"] 这样的容器中提取。字段提取也有细节：标题、价格、评分、评论数、是否赞助，都有各自更稳的 DOM 来源。

这种经验对 Agent 很有价值。没有它时，Agent 可能会从截图里猜按钮、反复尝试选择器；有了它之后，Agent 可以直接进入更稳定的数据提取路径。

更重要的是，这类 skill 还会记录陷阱。例如某些看似可用的选择器，在赞助结果或交叉推荐区域里会误读。这种坑只有实测过才知道。

例子：LinkedIn 邀请管理

LinkedIn 这类站点更接近真实账号工作流，风险也更高。

在邀请管理页里，Accept 和 Ignore 按钮的 aria-label 格式不同，不能简单地从一个推导另一个。有些邀请卡片里的 Accept 控件甚至不是 <button>，而是 <a>，普通 CDP 点击不一定能触发接受动作。

这种细节说明，真实网页自动化不是“定位到元素就结束”。按钮标签、事件绑定、软导航、组件实现方式，都会影响操作是否真的生效。

对 Agent 来说，这类经验还有一个安全含义：涉及社交账号、邀请、消息、发帖的操作，不应该完全托管。skill 可以记录路径和陷阱，但批量接受邀请、对外发送内容、修改账号资料这类动作，最好保留人工确认。

例子：Shopify Admin

Shopify Admin 的经验说明了另一个问题：后台系统往往不是一个页面，而是一堆嵌入式应用和复杂组件的组合。

很多 Shopify app 会运行在 iframe 里。Polaris React 输入框、Web Components、嵌入式 app 的交互方式也不同。某些输入框不能只用 element.value = ...，需要使用更接近真实键盘输入的 CDP keystrokes。

这类 skill 的价值在于，它让 Agent 先判断当前页面属于哪类 UI，再选择合适的操作方式。

同时，Shopify 的经验也强调“能不用浏览器就不用浏览器”：

只读商品和库存数据，优先用 Storefront API。
有 Admin API token 时，优先用 Admin API。
编辑主题代码时，优先用 Shopify CLI。
只有没有 API、一次性设置、探索后台时，才适合让浏览器介入。

这才是成熟的 Agent 工具选择逻辑。

例子：Browser Use Cloud

domain skills 不只服务网页点击，也可以记录围绕浏览器运行时的 API 经验。

Browser Use Cloud 的经验里，会记录如何通过 REST API 创建 cloud browser、列出正在运行的浏览器、清理 zombie browser、获取 liveUrl 和 cdpUrl 等信息。

这说明 skill 的边界并不局限于“某个网页按钮怎么点”。只要某类任务会反复出现，而且有稳定做法，就可以沉淀成 skill：

API 调用方式。
鉴权头格式。
请求和响应结构。
已验证状态码。
常见失败模式。
清理和回收资源的方法。

对 Agent 来说，这些都是可复用能力。

为什么这比临场推理更可靠

很多人期待大模型每次都能“自己看懂网页”。但真实任务里，只靠临场推理并不稳定。

原因很简单：

网页 UI 经常变化。
同一按钮可能有多种实现。
看得见不代表点得动。
能点击不代表操作真的生效。
有些任务本来就应该用 API，而不是浏览器。
有些操作需要人类确认，不能让模型自己决定。

domain skills 把这些经验写成文件后，有几个好处：

人类可以 review。
错误经验可以修正。
同一站点的经验可以持续积累。
新 Agent 可以直接继承旧经验。
临时任务发现可以变成长期知识。

这比把一切都塞进 prompt 或聊天上下文更稳。

团队可以怎么用

如果把 browser-harness 用在团队里，domain skills 可以变成一种轻量自动化知识库。

比较适合沉淀的内容包括：

内部后台的登录后路径。
报表导出流程。
常见弹窗处理方式。
哪些按钮需要人工确认。
哪些页面有 API 替代方案。
哪些选择器经过实测可靠。
哪些任务不允许 Agent 自动执行。

这类知识不必一开始就很完整。更实际的做法是从低风险、高频、可回滚的流程开始：先让 Agent 做只读、下载、整理、检查类任务。等流程稳定后，再把经验整理成 skill。

对团队管理者来说，skill 文件还有一个好处：它让自动化边界变得可见。你可以审查 Agent 知道什么、能做什么、应该停在哪里。

需要注意的边界

domain skills 能提高 Agent 成功率，但它不应该让高风险操作完全自动化。

几个边界要守住：

不记录密码、Cookie、token、客户数据和内部敏感 URL。
支付、删除、批量提交、账号变更、对外发布内容，要保留人工确认。
skill 要写明验证日期和适用范围。
站点改版后，要允许 skill 失效并重新验证。
不要把绕过风控、规避平台限制当成目标。

换句话说，domain skill 是让 Agent 更稳，不是让 Agent 无限制地做事。

简单结论

browser-harness 的 domain skills 机制说明了一件事：AI Agent 的浏览器自动化，不能只靠模型临场发挥。

一个可用的浏览器 Agent，至少需要三层能力：

底层控制能力：截图、点击、输入、下载、CDP、HTTP。
站点级知识：API 优先级、稳定选择器、组件陷阱、登录边界。
人类安全规则：凭据不交给模型，高风险操作要确认，敏感信息不写进 skill。

domain skills 补的是第二层。它让 Agent 带着验证过的经验进入网页任务，而不是每次都重新摸索。

参考资料：

browser-harness domain skills：https://github.com/browser-use/browser-harness/tree/main/agent-workspace/domain-skills
Amazon product-search skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/amazon/product-search.md
ArXiv scraping skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/arxiv/scraping.md
GitHub scraping skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/github/scraping.md
LinkedIn invitation-manager skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/linkedin/invitation-manager.md
Shopify admin skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/shopify-admin/README.md
Browser Use Cloud skill：https://github.com/browser-use/browser-harness/blob/main/agent-workspace/domain-skills/browser-use-cloud/cloud.md

browser-harness、Playwright、Puppeteer 怎么选？浏览器自动化工具对比

Sun, 24 May 2026 17:51:28 +0800

在浏览器自动化和自动化测试领域，Playwright 和 Puppeteer 是最常被拿来比较的两个工具。它们都可以控制浏览器、点击页面、抓取内容、生成截图或 PDF，也都和 Chrome DevTools Protocol 有很深关系。

但如果把 browser-use/browser-harness 放进来，问题就不只是“哪个测试框架更强”，而是变成了两类工具的对比：

Playwright / Puppeteer：面向人类工程师写确定性脚本。
browser-harness：面向 AI Agent 操作真实浏览器。

前者适合测试、爬虫和工程化自动化；后者更像给 Claude Code、Codex CLI、Gemini 这类 Agent 准备的浏览器控制层。

Playwright 和 Puppeteer 的关系

Puppeteer 最早由 Google Chrome 团队推出，天然服务于 Chromium 和 Chrome 自动化。它的 API 简洁，生态成熟，特别适合围绕 Chrome 做截图、PDF、页面抓取和轻量自动化。

Playwright 由微软维护，背后团队和早期 Puppeteer 有很深渊源。它吸收了 Puppeteer 的很多经验，同时把跨浏览器、自动等待、上下文隔离、测试报告和调试工具链做得更完整。

简单说：

只围绕 Chrome 做轻量任务，Puppeteer 仍然很顺手。
做跨浏览器 E2E 测试、复杂 SPA 自动化和团队测试工程，Playwright 通常更合适。

核心区别总览

维度	Puppeteer	Playwright
主导方	Google	Microsoft
浏览器支持	主要面向 Chrome / Chromium	Chromium、Firefox、WebKit
语言支持	主要是 JavaScript / TypeScript	JavaScript / TypeScript、Python、Java、.NET
自动等待	需要更多显式等待	Locator 和 auto-waiting 更完整
多上下文隔离	支持，但不是最突出的优势	BrowserContext 体验很强
工具链	简洁、成熟、偏基础	Codegen、Trace Viewer、测试报告更完整
典型场景	Chrome 自动化、截图、PDF、轻量抓取	跨浏览器 E2E 测试、复杂前端应用自动化

浏览器支持

Puppeteer 的优势在 Chrome。它和 Chromium 结合紧密，如果你的目标就是控制 Chrome、生成 PDF、截图、跑简单爬虫，Puppeteer 的心智负担很低。

Playwright 的优势在跨浏览器。它原生支持 Chromium、Firefox 和 WebKit。WebKit 这一点很关键，因为很多 Safari 相关问题不能只靠 Chrome 测出来。对需要覆盖桌面端、移动端和不同浏览器内核的应用来说，Playwright 更适合作为主力工具。

这也是两者选择的第一道分界线：只看 Chrome，可以用 Puppeteer；要认真做跨浏览器测试，优先 Playwright。

自动等待和稳定性

浏览器自动化最烦人的问题，往往不是“不会点击”，而是页面还没准备好。元素可能还没挂到 DOM，可能被遮挡，可能正在动画中，可能按钮还是 disabled。

Puppeteer 里经常会写：

1
2

await page.waitForSelector('#submit-btn');
await page.click('#submit-btn');

这没有问题，但等待逻辑需要工程师自己想清楚。页面越复杂，脚本里越容易出现各种 waitForSelector、waitForTimeout 和重试逻辑。

Playwright 的 Locator 机制和自动等待更完整：

`1`	`await page.locator('#submit-btn').click();`

在点击之前，Playwright 会自动检查元素是否可见、可操作、稳定、没有被遮挡，并在合理时间内重试。这对 React、Vue、Next.js 这类异步渲染很多的现代 Web 应用尤其重要，可以明显减少 flaky test。

多账号和上下文隔离

如果你要模拟多个用户，或者想让多个任务共享同一个浏览器进程但隔离 Cookie、LocalStorage 和 Session，BrowserContext 就很重要。

Puppeteer 也支持上下文隔离，但 Playwright 把这件事做成了核心能力。你可以在一个浏览器实例里快速创建多个独立 context，每个 context 像一个干净的浏览器环境，却不需要反复启动完整浏览器进程。

这对这些场景很有价值：

多账号并发测试。
多角色协作流程测试。
电商、IM、协作文档等多用户场景。
需要隔离 Cookie 和登录态的爬取任务。

工具链差异

Playwright 是更“工程化”的方案。它内置了很多测试开发会用到的工具：

codegen：在网页上操作，自动生成脚本。
Trace Viewer：失败后回看每一步的截图、DOM、网络请求和 console 日志。
Test Runner：支持断言、并行、重试、报告和项目矩阵。
Locator：支持按文本、角色、label、test id 等方式定位元素。

Puppeteer 则更像一个轻量浏览器控制库。它不臃肿，API 直接，适合嵌入脚本、服务端任务和自定义自动化流程。

如果你要搭企业级测试体系，Playwright 的配套工具会省很多事。如果你只是要写一个 Node.js 脚本，把网页转 PDF 或定时截图，Puppeteer 反而更干脆。

browser-harness 放在哪里

browser-harness 和 Playwright、Puppeteer 不是同一类工具。

Playwright 和 Puppeteer 主要假设“人类写脚本”。人类工程师要决定选择器、等待条件、断言逻辑和异常处理。它们追求的是确定性：同样的脚本，在同样的页面状态下，应该给出同样的结果。

browser-harness 主要假设“AI Agent 操作浏览器”。它的目标不是提供一套巨大的高级 API，而是通过 CDP 连接真实 Chrome，把截图、坐标点击、DOM、网络请求和 helper 暴露给 Agent。Agent 可以观察页面、判断下一步、遇到缺能力时补 helper，再把站点经验沉淀成 skill。

这就让它更适合开放任务：

登录后台后下载账单。
在内部系统里填一组表单。
处理经常改版的 OA 或 SaaS 页面。
按用户目标探索页面，而不是执行固定脚本。
让 Claude Code、Codex CLI 这类工具拥有浏览器操作能力。

三者核心对比

维度	Puppeteer	Playwright	browser-harness
面向对象	人类工程师	人类工程师和测试团队	AI Agent
主要目标	控制 Chrome	稳定跨浏览器自动化	让 Agent 操作真实浏览器
脚本方式	手写 JS/TS 自动化	手写脚本 + 测试框架	用户下目标，Agent 分步执行
元素定位	CSS、XPath、DOM API	Locator、文本、角色、CSS	截图视觉、坐标、DOM、CDP
等待机制	更多手动控制	自动等待很强	由 Agent 观察和调整
浏览器环境	通常启动自动化浏览器	通常启动测试浏览器	常连接真实 Chrome
最适合	Chrome 脚本、截图、PDF、轻量抓取	E2E 测试、跨浏览器验证、复杂 SPA	AI 助手、开放网页任务、真实账号工作流

代码体感对比

Puppeteer 更像直接控制 Chrome：

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.waitForSelector('#submit-btn');
  await page.click('#submit-btn');

  await browser.close();
})();

Playwright 更强调 Locator 和自动等待：

const { chromium } = require('playwright');

(async () => {
  const browser = await chromium.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');

  await page.locator('#submit-btn').click();

  await browser.close();
})();

browser-harness 的使用体感则完全不同。你通常不是写完整脚本，而是在 Agent 环境里下达目标：

`1`	`帮我打开后台，下载上个月的账单，并整理成报销用的文件。`

Agent 会借助 browser-harness 反复执行类似流程：

截图，理解当前页面。
点击某个坐标或定位某个元素。
输入文字、上传文件、下载文件。
遇到弹窗时判断如何关闭。
缺少 helper 时补充代码。
把可复用流程沉淀为 domain skill。

这不是传统测试脚本的写法，而是浏览器 Agent 的工作方式。

怎么选

选择 Puppeteer，通常是因为：

项目主要跑在 Node.js 里。
只需要 Chrome 或 Chromium。
任务是截图、PDF、简单页面抓取或轻量自动化。
你希望 API 简洁，依赖少，自己控制更多细节。
你对 Chrome DevTools Protocol 有较深依赖。

选择 Playwright，通常是因为：

你要做标准 UI 自动化或 E2E 测试。
需要覆盖 Chromium、Firefox 和 WebKit。
团队主语言可能是 Python、Java 或 C#。
页面是复杂 SPA，异步状态多，容易出现 flaky test。
你需要 codegen、Trace Viewer、测试报告和并行测试。

选择 browser-harness，通常是因为：

你在开发或使用 AI Agent。
你希望模型像人一样操作真实浏览器。
任务步骤不固定，需要边看页面边判断。
目标网站经常改版，或者弹窗、iframe、shadow DOM 很多。
你想把真实网页工作流交给 Claude Code、Codex CLI 等工具处理。

简单结论

Playwright 和 Puppeteer 是浏览器自动化工具，核心是让人写出可靠脚本。两者相比，Puppeteer 更轻、更贴近 Chrome；Playwright 更完整、更适合跨浏览器测试和复杂前端应用。

browser-harness 则是另一个方向：它不是为了取代 Playwright 或 Puppeteer 写测试，而是为了让 AI Agent 接管真实浏览器。它牺牲了一部分传统脚本的确定性，换来更强的开放任务适应能力。

所以答案不是三选一，而是按任务分层：

测试工程：优先 Playwright。
Chrome 轻量脚本：Puppeteer 很合适。
AI Agent 上网办事：看 browser-harness。

参考资料：

browser-use/browser-harness：https://github.com/browser-use/browser-harness
Playwright 官方文档：https://playwright.dev/
Puppeteer 官方文档：https://pptr.dev/
Chrome DevTools Protocol：https://chromedevtools.github.io/devtools-protocol/

browser-harness 是什么？AI Agent 接管真实 Chrome 的浏览器自动化工具

Sun, 24 May 2026 17:19:54 +0800

browser-use/browser-harness 是一个面向 AI Agent 的浏览器控制工具。它的目标不是再做一层复杂的自动化框架，而是把大模型直接连到真实 Chrome，通过 CDP 完成浏览、点击、截图、下载、上传和表单操作。

项目 README 对自己的定位很明确：用一层很薄、可编辑的 CDP harness，让 LLM 直接连接真实浏览器；当任务中缺少 helper 时，Agent 可以在执行过程中补上代码，并把可复用经验沉淀成 domain skills。

这类工具值得关注，是因为浏览器仍然是很多真实工作的入口：后台系统、SaaS 面板、电商页面、招聘网站、CRM、报销系统、云控制台、文档平台，往往没有稳定 API，或者 API 权限比网页权限更难拿到。让 Agent 能可靠地操作浏览器，本质上是在补齐“最后一公里”的自动化能力。

browser-harness 是什么

从结构看，browser-harness 更像一个给 Agent 用的浏览器运行时，而不是普通用户手动点击的浏览器插件。

它的核心思路有几个：

直接连接 Chrome 或 Chromium 浏览器。
通过 CDP WebSocket 操作页面。
让 Agent 用截图、坐标点击、DOM、网络请求和原始 CDP 组合完成任务。
把任务相关 helper 放在 agent-workspace/agent_helpers.py。
把站点相关经验沉淀到 agent-workspace/domain-skills/。
保持核心很薄，避免做成庞大的自动化平台。

README 中提到，项目核心架构大约是 4 个核心文件、约 1000 行代码，主要包括 install.md、SKILL.md、src/browser_harness/、agent-workspace/agent_helpers.py 和 agent-workspace/domain-skills/。

这种设计的重点不是“内置所有网站能力”，而是给 Agent 一个足够贴近真实浏览器的操作层，让它在具体任务里补齐缺失能力。

它和传统浏览器自动化有什么不同

传统浏览器自动化通常围绕测试框架展开，例如 Playwright、Selenium 或 Puppeteer。它们适合写确定性的测试脚本：打开页面、定位元素、点击、断言结果。

browser-harness 面向的是另一类任务：用户说一句目标，Agent 自己探索页面、判断状态、处理弹窗、补 helper、复用站点经验。它强调的是交互过程中的适应性。

差异可以这样理解：

Playwright 更适合人写脚本，Agent 执行脚本。
browser-harness 更适合 Agent 边看页面边行动。
传统自动化偏固定流程。
browser-harness 偏开放任务。
传统脚本常依赖选择器。
browser-harness 鼓励先截图、再按可见界面行动，必要时再退回 DOM 或 CDP。

这并不意味着它要替代 Playwright。对稳定测试来说，Playwright 仍然更成熟。browser-harness 的价值在于把真实网页变成 Agent 可操作的环境，尤其适合那些页面结构复杂、步骤不固定、需要临场判断的任务。

为什么强调真实 Chrome

很多浏览器 Agent 工具会使用隔离的无头浏览器。这样部署简单，也适合批量任务，但它有一个现实问题：用户真实工作里的登录态、扩展、历史记录、书签和日常浏览器环境并不一定能直接复用。

browser-harness 支持连接本机 Chrome，也支持 Browser Use cloud browser。对本机浏览器，它提供两种方式：

通过 chrome://inspect/#remote-debugging 允许当前 Chrome 实例被连接。
用 --remote-debugging-port=9222 --user-data-dir=... 启动一个隔离 profile。

如果要让 Agent 帮你处理真实账号里的任务，项目文档更倾向于第一种方式，因为它能复用日常 Chrome 的登录态、扩展和书签。如果要做无人值守自动化，或者不希望被弹窗打断，则更适合使用隔离 profile 或云浏览器。

这里的取舍很清楚：真实浏览器更贴近用户工作流，但安全边界也更敏感；隔离浏览器更适合自动化，但需要重新处理登录和环境。

可编辑 helper 和 domain skills

browser-harness 最有意思的地方，是它把“Agent 会学到什么”设计进了项目结构。

agent-workspace/agent_helpers.py 用来放任务中临时补出来的 helper。比如 Agent 做文件上传时发现现有能力不够，可以补一个稳定的上传函数；下次再遇到类似页面，就不用从零开始。

agent-workspace/domain-skills/ 则用来放站点级经验。README 里举的方向包括 LinkedIn outreach、Amazon 下单、报销系统等。项目建议不要手写这些 skill，而是让 Agent 在真实任务中发现可复用流程后再生成，这样更贴近实际页面行为。

这个思路很适合浏览器自动化。因为网页自动化的难点往往不是“怎么点击按钮”，而是：

某个网站的登录后页面怎么跳转。
哪些弹窗会挡住主流程。
哪些 selector 稳定，哪些只是临时样式名。
上传、下载、iframe、shadow DOM、跨域组件怎么处理。
某个后台系统有哪些隐藏等待和异步状态。

这些知识如果只留在一次运行日志里，很快就会丢掉。把它们沉淀成 domain skills，才可能让 Agent 越用越顺。

适合哪些场景

browser-harness 更适合以下任务：

帮用户操作真实网页后台。
在没有 API 的系统里完成重复流程。
登录态依赖强的个人或企业网页任务。
需要截图判断页面状态的复杂交互。
Agent 需要在执行中补工具、补站点经验。
多个子 Agent 各自使用独立浏览器执行任务。
研究浏览器 Agent 的运行时设计。

具体例子包括：整理网页表格、提交内部系统表单、下载账单、上传文件、处理报销流程、检查订单状态、在 SaaS 控制台里配置资源、从登录后的网页提取信息。

如果任务只是抓取静态网页，未必需要浏览器。项目自己的 SKILL.md 也提到，静态页面可以直接用 HTTP 批量获取；浏览器应该留给真正需要页面状态、登录态和交互的场景。

需要注意的风险

让 AI Agent 接管真实 Chrome，很强，也很危险。

第一，权限边界要清楚。真实 Chrome 里可能有邮箱、支付后台、云控制台、公司系统和个人账号。Agent 一旦能操作浏览器，就等于获得了这些网页权限的一部分。

第二，不要把凭据交给模型。遇到登录页、支付验证、二次确认等敏感步骤，应该让用户自己处理。Agent 可以等待登录完成，但不应该从截图里读取或输入密码、验证码、支付信息。

第三，自动化不等于可托管。很多网页任务看似简单，但中间可能出现风控、误点击、数据删除、批量提交、不可逆操作。适合先从只读、低风险、可回滚的流程开始。

第四，domain skills 需要避免泄露隐私。站点经验可以公开，但不要把账号、内部 URL、客户数据、坐标流水账或一次性任务细节写进去。

第五，真实浏览器连接方式要谨慎选择。如果要复用日常登录态，使用当前 Chrome 很方便；如果要跑长时间自动化，隔离 profile 或云浏览器更可控。

对 AI Agent 工具的意义

browser-harness 代表了一种很务实的 Agent 工具路线：少做平台，多给模型一个可以直接触达真实环境的接口。

过去很多 Agent 失败在两端。一端是模型会推理，但摸不到真实页面；另一端是自动化框架很强，但需要人先把流程写死。browser-harness 试图把这两端接起来：浏览器负责真实世界的状态，Agent 负责观察、判断和补工具。

这也是“自我改进 harness”的意义。它不是说 Agent 会神奇地变聪明，而是把可复用的操作经验放到项目结构里，让下一次任务少走弯路。

对开发者来说，browser-harness 的价值主要在三个层面：

作为个人 Agent 的浏览器控制层。
作为研究浏览器自动化和 Agent 工作流的样本。
作为把网页流程变成可复用技能的实验框架。

它不是所有浏览器自动化问题的答案，但它给出了一个清晰方向：当 Agent 真正要帮人做事时，工具层不只要能调用 API，也要能理解和操作人类每天使用的网页界面。

简单结论

browser-use/browser-harness 值得关注，不是因为它包装了多少高级功能，而是因为它把浏览器 Agent 的几个关键问题摆在了台面上：真实 Chrome、CDP、截图驱动、可编辑 helper、站点技能沉淀，以及用户权限边界。

如果你只是写稳定端到端测试，继续用 Playwright 或 Selenium 就很好。如果你想让 Codex、Claude Code 这类 Agent 直接帮你处理真实网页任务，browser-harness 提供了一个更贴近 Agent 工作方式的入口。

真正使用时，建议从低风险任务开始：先让它读页面、截图、提取信息，再逐步尝试点击和提交。等你确认它能稳定识别页面状态，再考虑让它接管更长的流程。

参考资料：

GitHub 项目：https://github.com/browser-use/browser-harness
README：https://github.com/browser-use/browser-harness/blob/main/README.md
安装文档：https://github.com/browser-use/browser-harness/blob/main/install.md
使用说明：https://github.com/browser-use/browser-harness/blob/main/SKILL.md

GitHub AI 开源项目分类整理：从 Coding Agent 到 RAG 知识库

Thu, 21 May 2026 08:53:13 +0800

这里按应用方向列出 GitHub AI 项目，覆盖 AI 编程与 Coding Agent、Agent 技能与工作流、RAG 与知识库、多模态创作、本地模型与推理、垂直应用与自动化、AI 应用开发基础设施等方向。后续新增项目时，也可以继续按这个结构补充。

分类合计

分类	项目数	适合先看的人
AI编程与 Coding Agent	22	经常使用 Claude Code、Codex、Cursor、终端 Agent 或代码库自动化的人
Agent 技能与工作流	7	想把 AI 编程、科研、创作流程标准化的人
RAG、知识库与记忆	7	需要文档检索、知识库、长期记忆、网页抓取和结构化抽取的人
垂直应用与自动化	7	想看金融、交易、闲鱼监控、桌面操作、浏览器自动化等落地场景的人
多模态与内容创作	5	做图片、视频、语音转写、提示词库和内容分发的人
AI 应用开发基础设施	5	构建 AI 应用、浏览器自动化、Prompt/MCP 工具链的人
本地模型与推理	1	关心本地 DeepSeek、推理引擎和硬件适配的人

这个分布可以看出当前 AI 开源项目的几个高频方向：AI 编程工具明显最多，其次是 Agent 工作流、RAG 知识库和具体应用场景。纯模型推理项目数量不多，因为很多本地部署内容并不是单独介绍某个 GitHub 项目，而是围绕模型、显卡或部署方案展开。

AI编程与 Coding Agent

这一类聚焦代码理解、代码修改、工程流程和终端 Agent，是数量最多的一组。共 22 个项目。

项目	文章	GitHub	核心用途	适合人群
Ralph	Ralph 是什么：把 Claude Code 和 Amp 变成可循环执行的自主开发流程	snarktank/ralph	让 Claude Code / Amp 按 PRD、计划、执行、评审循环推进任务	想把 Agent 编程流程拉直的人
Claude-Mem	Claude-Mem：给 Claude Code 加上跨会话长期记忆	thedotmack/claude-mem	为 Claude Code 增加跨会话记忆	高频使用 Claude Code 的开发者
Claude Code Hooks Mastery	Claude Code Hooks Mastery：13 个 Hooks 生命周期与自动化控制入门	disler/claude-code-hooks-mastery	学习 Claude Code Hooks 生命周期和自动化控制	想定制 Claude Code 流程的人
Compound Engineering Plugin	Compound Engineering Plugin：把 AI 编程变成计划、执行、评审的工程循环	EveryInc/compound-engineering-plugin	把 AI 编程拆成计划、执行、评审循环	关注工程化 AI 编程的人
free-claude-code	free-claude-code：用代理把 Claude Code 接到 OpenRouter、DeepSeek 和本地模型	Alishahryar1/free-claude-code	通过代理把 Claude Code 接到不同模型后端	想降低 Claude Code 使用成本的人
Hermes Agent	Hermes Agent 是什么：简介、优点、快速上手与 OpenClaw 对比	NousResearch/hermes-agent	本地 Agent 框架，支持工具调用和任务执行	想跑本地 Agent 的用户
OpenHarness	OpenHarness 是什么：这个开源 Agent Harness 能做什么	HKUDS/OpenHarness	Agent Harness 与多 Agent 执行框架	研究 Agent 编排的人
CodexBridge	Codex 怎么接入国产大模型？OpenAI 兼容接口与 CodexBridge 使用思路	begonia599/CodexBridge	帮 Codex 接入 OpenAI 兼容模型接口	想把 Codex 接到国产模型的人
ccx	Codex 怎么接入国产大模型？用 CCX 统一管理 OpenAI 兼容 API	BenedictKing/ccx	统一管理 Claude、Codex、Gemini 等 API 代理	多模型切换用户
cc-haha	cc-haha 是什么？一个把 Claude Code 做成桌面工作台的项目	NanmiCoder/cc-haha	Claude Code 桌面工作台与 Computer Use 入口	喜欢图形界面的 Claude Code 用户
DeepSeek-TUI	DeepSeek-TUI：把 DeepSeek V4 变成终端里的编程智能体	Hmbown/DeepSeek-TUI	在终端里运行 DeepSeek 编程 Agent	DeepSeek 与命令行用户
Open Design	Open Design 项目解析：把 Claude Code、Codex 变成 AI 设计工具	nexu-io/open-design	让 Claude Code / Codex 参与设计生成	想用 Agent 做设计原型的人
agentmemory	agentmemory 项目解析：给 Claude Code、Codex 和 Cursor 加持久记忆	rohitg00/agentmemory	给 Coding Agent 增加持久记忆层	长期维护项目的开发者
Graphify	Graphify 解决 Claude Code 最大局限：把代码库变成 AI 可查询知识图谱	safishamsi/graphify	把代码库转成知识图谱，降低 Agent 重复读文件成本	大型代码库用户
oh-my-pi	oh-my-pi 是什么？一个把终端、IDE 和调试器打通的 AI 编程助手	can1357/oh-my-pi	把终端、IDE、LSP 和调试器连接起来，作为本地 AI 编程控制台	想把命令行和 IDE 工作流打通的开发者
Claude Plugins Official	Claude Code 也有插件市场了：能装什么、怎么装、要注意什么	anthropics/claude-plugins-official	Claude Code 官方插件目录和安装入口	想给 Claude Code 扩展能力的用户
CodeGraph	CodeGraph 是什么？给 Claude Code、Codex 和 Cursor 加一个本地代码地图	colbymchenry/codegraph	为代码库生成本地索引和关系图，帮助 Coding Agent 理解项目	维护中大型代码库的开发者
CC Switch	CC Switch：一个桌面工具统一管理 Claude Code、Codex、Gemini CLI 和 OpenClaw	farion1231/cc-switch	管理多个 AI CLI 工具和账号/配置切换	同时使用多套 CLI 的人
Warp	Warp 开源：从终端到 Agentic Development Environment	warpdotdev/warp	Agentic 终端与开发环境	终端重度用户
opencode	opencode、Claude Code、Codex 有什么区别？开源 AI 编程工具使用指南	anomalyco/opencode	开源 AI 编程 Agent	想找 Claude Code / Codex 替代品的人
9Router	9Router：把 Claude Code、Codex、Cursor 接到同一个 AI 路由器	decolua/9router	AI 编程模型路由与 token 成本控制	多工具、多模型用户
goose	goose：桌面端、CLI 和 API 一体的开源 AI Agent	aaif-goose/goose	桌面、CLI、API 一体的开源 Agent	想要通用 Agent 工作台的人

Agent 技能与工作流

这一类更关注把 AI 能力固化成可重复的技能、流程和规格。共 7 个项目。

项目	文章	GitHub	核心用途	适合人群
mattpocock/skills	拒绝 Vibe Coding：Matt Pocock 的 skills 仓库给 AI 编程补上工程约束	mattpocock/skills	用 Skills 约束 AI 编程流程	想给 Agent 加工程规范的人
Superpowers	Superpowers：把 Coding Agent 拉回工程流程的技能框架	obra/superpowers	Agentic skills framework 与软件开发方法论	想系统化使用 Coding Agent 的人
Prompt-Vault	Prompt-Vault：一个适合测试 AI 编程能力的 Prompt 规格库	w512/Prompt-Vault	收集可测试 AI 编程能力的 prompt 规格	做模型/工具评测的人
web-video-presentation	web-video-presentation：把文章做成可录屏网页视频的 Agent Skill	ConardLi/garden-skills	把文章转成可录屏网页视频的 Skill	内容创作者和自动化制作用户
nuwa-skill	nuwa-skill：把“蒸馏一个人”从灵感变成可执行流程	alchaincyf/nuwa-skill	用 Skill 复刻人物表达和思维流程	做风格化 Agent 的人
Scientific Agent Skills	Scientific Agent Skills：把科研工作流交给 AI Agent 的技能库	K-Dense-AI/scientific-agent-skills	科研工作流 Skill 集合	科研、数据分析和技术写作用户
easy-vibe	easy-vibe：给 Vibe Coding 初学者的一张学习地图	datawhalechina/easy-vibe	Vibe Coding 入门学习地图	AI 编程新手

RAG、知识库与记忆

这一类主要解决文档检索、知识库构建、长期记忆和结构化抽取问题。共 7 个项目。

项目	文章	GitHub	核心用途	适合人群
LangExtract	Google LangExtract：用 LLM 从长文本里抽取结构化数据	google/langextract	从长文本中抽取结构化信息	做信息抽取和数据处理的人
qmd	qmd：给 AI Agent 使用的本地 Markdown 文档搜索工具	tobi/qmd	本地 Markdown 文档搜索	用 Markdown 管理知识库的人
Firecrawl	Firecrawl 项目整理：给 AI Agent 用的网页搜索、抓取与交互 API	firecrawl/firecrawl	网页抓取、搜索和结构化数据入口	做 RAG 和 Agent 数据入口的人
RAGFlow	RAGFlow 项目整理：开源 RAG 引擎的功能与使用方法	infiniflow/ragflow	开源 RAG 引擎	企业知识库和文档问答用户
OpenHuman	OpenHuman 速读：开源个人 AI Agent 的桌面化路线	tinyhumansai/openhuman	本地优先的个人 AI Agent 与记忆层	想整合个人数据的人
OpenKB	OpenKB：把文档编译成可持续更新的 LLM 知识库	VectifyAI/OpenKB	把文档编译成可更新知识库	文档知识库维护者
PageIndex	PageIndex 是什么？不用向量库的推理式 RAG 文档索引解析	VectifyAI/PageIndex	不依赖向量库的推理式文档索引	关注 RAG 新路线的人

多模态与内容创作

这一类面向图片、视频、语音转写和内容分发等创作场景。共 5 个项目。

项目	文章	GitHub	核心用途	适合人群
rembg	rembg 项目整理：本地图片背景移除工具	danielgatis/rembg	本地图片背景移除	电商、美工和图片处理用户
awesome-gpt-image-2-prompts	GPT-Image 2 提示词宝库：电商、海报、人像、UI 全收录	EvoLinkAI/awesome-gpt-image-2-prompts	GPT-Image 2 提示词和案例库	AI 绘图和提示词用户
faster-whisper	faster-whisper：更快的 Whisper 转写引擎	SYSTRAN/faster-whisper	高性能语音转文字	做字幕、转写和语音处理的人
Pixelle-Video	Pixelle-Video：一句主题生成短视频的开源 AI 引擎	AIDC-AI/Pixelle-Video	一句话生成短视频工作流	短视频和 AIGC 内容创作者
AiToEarn	内容发太多平台太累？AiToEarn 想用 AI Agent 帮创作者省点事	yikart/AiToEarn	多平台内容分发与创作者自动化	内容运营和创作者

本地模型与推理

这一类关注本地模型运行和推理实验，当前数量较少。共 1 个项目。

项目	文章	GitHub	核心用途	适合人群
ds4	本地运行 DeepSeek 4：Antirez ds4 在 Apple Silicon Mac 上的尝试	antirez/ds4	在 Apple Silicon 上尝试运行 DeepSeek 4	本地模型和推理实验用户

垂直应用与自动化

这一类是把 Agent 或 AI 能力落到金融、交易、浏览器、桌面和电商监控等具体场景。共 7 个项目。

项目	文章	GitHub	核心用途	适合人群
TradingAgents-CN	TradingAgents-CN：面向中文用户的多智能体金融交易研究框架	hsliuping/TradingAgents-CN	多智能体金融交易研究框架	量化、金融和 Agent 研究者
FinceptTerminal	FinceptTerminal：开源金融终端、量化研究和 AI Agent 工作台	Fincept-Corporation/FinceptTerminal	金融终端、量化研究和 AI Agent 工作台	金融分析和量化用户
Anthropic financial-services	Anthropic financial-services：把金融 Agent 场景做成可复用模板	anthropics/financial-services	金融服务 Agent 模板	做金融 AI 方案的人
ai-goofish-monitor	ai-goofish-monitor：用 AI 自动盯闲鱼商品的开源监控系统	Usagi-org/ai-goofish-monitor	AI 商品监控和闲鱼自动化	二手交易监控用户
CloakBrowser	CloakBrowser 是什么？给 Playwright 和 Puppeteer 换一个更像真实用户的浏览器	CloakHQ/CloakBrowser	更像真实用户的浏览器自动化环境	浏览器自动化和 Agent 操作场景
UI-TARS-desktop	让 AI 自己操作电脑？UI-TARS-desktop 把桌面、浏览器和工具都接了起来	bytedance/UI-TARS-desktop	桌面、浏览器和工具操作 Agent	想让 AI 操作电脑的人
AI-Trader	AI-Trader 是什么？一个让 AI Agent 发布交易信号、做模拟交易的平台	HKUDS/AI-Trader	AI Agent 交易信号和模拟交易平台	金融 Agent 与交易研究用户

AI 应用开发基础设施

这一类提供构建 AI 应用和 Agent 工具链所需的基础组件。共 5 个项目。

项目	文章	GitHub	核心用途	适合人群
Prompt Optimizer	Prompt Optimizer：开源提示词优化、测试与 MCP 工具	linshenkx/prompt-optimizer	提示词优化、测试和 MCP 工具	做 prompt 工程和应用调参的人
Playwright CLI	Playwright CLI 使用入门：安装、Skills、会话管理与常用命令	microsoft/playwright-cli	面向 coding agent 的浏览器自动化 CLI	需要浏览器操作能力的 Agent 用户
Vercel AI SDK	Vercel AI SDK 是什么？TypeScript 开发者构建 AI 应用的统一工具包	vercel/ai	TypeScript AI 应用开发 SDK	前端和全栈开发者
CLIProxyAPI	CLIProxyAPI：把 Codex、Claude Code、Gemini CLI 统一封装成 API	router-for-me/CLIProxyAPI	把多个 AI CLI 和 OAuth 登录态封装成兼容 API	想统一接入 Codex、Claude Code、Gemini CLI 的用户
CLIProxyAPI Management Center	CLIProxyAPI Management Center：给 CLIProxyAPI 配一个可视化管理后台	router-for-me/Cli-Proxy-API-Management-Center	CLIProxyAPI 的 Web 管理界面，管理配置、账号、日志和 OAuth	把 CLIProxyAPI 当团队网关或账号池使用的人

Google I/O 2026 主要内容总结：Gemini 3.5、Omni、Antigravity 与系统级 Agent

Thu, 21 May 2026 00:07:06 +0800

Google I/O 2026 的主线很清楚：Google 正在把 Gemini 从“模型”和“聊天助手”推进到一个更完整的 Agent 生态。它不只是回答问题，而是要进入搜索、Android、开发工具、视频创作、购物、Workspace、硬件和企业平台，帮助用户完成更长链路的任务。

本文按官方发布信息和开发者视角，整理 Google I/O 2026 的主要内容。实际开发时仍应以 Google、Android Developers 和 Gemini API 官方文档为准。

一句话总结

Google I/O 2026 的关键词是 agentic Gemini era。

Google 发布或强化了几条线：

Gemini 3.5 Flash：强调速度、行动能力和 Agent 工作流。
Gemini Omni：从任意输入生成内容，重点从视频创作和编辑开始。
Gemini app：从聊天助手走向主动、全天候、可执行任务的个人 Agent。
Google Antigravity 2.0：从 AI 编程工具升级为 Agent 优先的开发平台。
Gemini API Managed Agents：通过 API 创建能推理、用工具、执行代码的托管 Agent。
Google AI Studio：扩展到移动端、Android 原生支持和项目导出到 Antigravity。
Search、Shopping、YouTube、Workspace、Android：都在接入更强的 Gemini 和 Agent 能力。

换句话说，Google 不再只展示“模型有多聪明”，而是在展示“模型如何进入产品、工具和系统，真正替用户执行任务”。

Gemini 3.5 Flash：从提示词走向行动

Gemini 3.5 是 Google 在 I/O 2026 推出的新一代模型系列，首个公开重点是 Gemini 3.5 Flash。

Google 对它的定位不是单纯“更快的聊天模型”，而是用于真实 Agent 工作流的高速引擎。官方开发者文章提到，3.5 Flash 结合前沿智能和高速度，用来支撑从 prompt 到 action 的转变。

它的主要意义在于：

面向 Agent 和 coding 场景优化。
支持更长链路任务和工具调用。
在 Antigravity、Gemini API、Google AI Studio、Android Studio、Gemini Enterprise 等入口提供。
更适合需要快速响应、多轮执行和频繁工具调用的应用。

对开发者来说，Gemini 3.5 Flash 不只是一个模型选项，而是 Google 新 Agent 工具链的默认动力源之一。

Gemini Omni：视频和世界模型能力成为重点

Gemini Omni 是 I/O 2026 另一个核心发布。Google 对它的描述是：从任意输入创作内容，当前重点从视频开始。

它的看点主要有三类：

多模态输入：文本、图像、视频、音频等都可以作为参考。
视频编辑：用户可以用自然语言多轮修改视频，而不是一次性生成后就结束。
世界理解：强调物理、场景、动作、叙事和视听一致性。

这意味着 AI 视频工具的方向正在从“输入一句提示词生成短片”走向“像和剪辑师沟通一样逐轮修改”。对创作者来说，真正有价值的不是一次生成，而是可控、可追踪、可迭代的编辑流程。

Gemini App：从聊天助手变成全天候个人 Agent

Google 也把 Gemini app 明确推向更 Agent 化的方向。官方文章提到，Gemini app 正在变得更主动，提供日常简报和全天候帮助。

几个重点包括：

Gemini 3.5 Flash 进入 Gemini app。
新 UI 和更动态的交互体验。
Gemini Spark 这类个人 AI Agent 概念。
Proactive daily briefs，主动整理用户每天需要关注的信息。
更强调 7×24 小时后台协助，而不是用户每次都主动发起聊天。

这部分对普通用户影响最大。过去 Gemini 更像“你问我答”的助手；I/O 2026 之后，Google 想让它更像能持续跟进任务、主动提醒、跨产品协同的个人智能体。

Antigravity 2.0：开发者工具转向 Agent 优先

开发者侧最重要的发布之一是 Google Antigravity 2.0。

Google 将 Antigravity 定位为 agent-first development platform。I/O 2026 之后，它不只是帮助写代码，而是要帮助开发者从想法、原型、Agent 编排到生产应用交付。

官方列出的核心变化包括：

Antigravity 2.0 独立桌面应用。
支持多 Agent 并行编排。
支持动态 subagents。
支持后台定时任务。
与 Google AI Studio、Android、Firebase 等生态集成。
提供 Antigravity CLI，面向终端用户。
提供 Antigravity SDK，用于自定义 Agent 行为和部署。

这说明 AI 编程工具正在从“代码补全 / 对话生成”进入下一阶段：开发者要管理的是多个可执行 Agent，而不只是一个聊天窗口。

Gemini API Managed Agents：把 Agent 托管成 API 能力

Google 还推出了 Managed Agents in the Gemini API。

官方描述中，这类 Agent 可以通过一次 API 调用创建，具备推理、工具使用和在隔离 Linux 环境中执行代码的能力，并且由 Antigravity agent harness 提供支持。

这件事对开发者很关键：

不必自己搭完整 Agent 运行环境。
可以获得持久、隔离的执行环境。
多轮交互可以保留文件和状态。
可以用 markdown 技能、自定义指令和模板扩展 Agent。
可通过 Interactions API 和 Google AI Studio 使用。

如果这条线成熟，Agent 平台会越来越像云服务：开发者不再只调用模型，而是调用一个带状态、工具、执行环境和安全边界的 Agent。

Google AI Studio：从 prompt playground 走向应用生成入口

I/O 2026 中，Google AI Studio 的定位也更进一步。

重点变化包括：

Google AI Studio mobile app，可在移动端捕捉想法和生成原型。
Workspace API 集成，让 Agent 能更自然地接入 Google Workspace。
项目可导出到 Antigravity，带着上下文继续本地开发和生产化。
增加 Android 原生支持，可以用 prompt 构建 Android 应用。
支持对接 Google Play Console，把应用发布到测试轨道。

这让 AI Studio 从“调提示词和试模型”变成“从想法到应用”的入口。它和 Antigravity 的关系也更清楚：AI Studio 适合快速构思和生成，Antigravity 适合继续开发、编排、调试和交付。

Android 与 AppFunctions：移动端 Agent 的关键接口

Android 系统级 Agent 是这次值得单独看的方向，但需要用更准确的接口和产品边界来理解。

当前最值得关注的是 Android 官方的 AppFunctions。官方文档说明，AppFunctions 是一种 Android 平台 API，并带有 Jetpack 库，可以让应用把自身能力暴露给智能体、助手和其他有权限的调用方。它还简化了 Android MCP 集成。

它的意义在于：移动端自动化不再只能依赖截图、OCR、模拟点击和 UI 控件定位。

传统移动端自动化路径是：

识别屏幕。
找按钮。
模拟点击。
等待页面变化。
出错后重试。

AppFunctions 的方向是：

应用声明自己能做什么。
Agent 在授权下调用这些能力。
系统负责权限、调用边界和安全约束。

这会影响 Android 应用设计。未来应用不只要做给人看的 UI，还要把核心功能设计成可被 Agent 调用的能力接口。

Search、购物和内容产品也在 Agent 化

Google I/O 2026 的变化不只在模型和开发者工具里，搜索和消费产品也在同步变化。

官方 I/O 汇总中提到：

Search 进入新的 AI Search 阶段。
Information agents 出现在搜索场景中。
Gemini Spark 和 Daily Brief 进入 Gemini app。
Universal Cart 让购物车更智能。
Ask YouTube 让视频内容可以被对话式查询和跳转。
Gemini 能力继续扩展到更多产品和形态。

这些发布说明 Google 的 Agent 方向不是单点产品，而是横向铺到搜索、视频、购物、办公、移动和硬件场景中。

对开发者的实际影响

Google I/O 2026 对开发者最大的影响，不是“又多了一个模型”，而是开发对象变了。

以前开发者主要构建：

App。
网站。
API。
插件。
自动化脚本。

接下来还要构建：

可被 Agent 调用的应用能力。
多 Agent 工作流。
有状态的工具执行环境。
可审计的自动化流程。
人在回路确认机制。
与 MCP、AppFunctions、Workspace API、Playwright、Firebase 等工具的集成。

软件会越来越像“能力集合”，而不仅是“界面集合”。谁能把自己的能力清晰、可靠、安全地开放给 Agent，谁就更容易进入用户的自动化任务链。

对移动端自动化的影响

移动端自动化会从“GUI 优先”逐步变成“接口优先，GUI 兜底”。

短期看，截图识别、OCR、模拟点击、浏览器自动化仍然有价值，因为大量旧应用没有标准接口。

长期看，只要 Android AppFunctions、MCP 和系统级权限模型成熟，稳定的任务执行会更偏向：

优先调用应用声明的能力。
必要时调用系统接口。
再必要时用 GUI 自动化兜底。

这会改变 RPA、移动端 Agent、测试工具和应用生态。应用越愿意开放能力，越容易被系统级 Agent 调用；不开放能力的应用，可能仍然只能被“看屏幕、点屏幕”的旧方式操作。

安全、权限和审计会成为硬约束

Agent 能力越强，风险越大。

如果 Agent 可以跨应用执行任务、调用支付、修改设置、访问文件和读取上下文，就必须有清晰的安全边界：

权限分级。
用户显式授权。
敏感操作二次确认。
沙箱隔离。
操作日志。
可撤销和可回滚。
企业审计与合规。

这也是为什么 Google 会强调托管 Agent 的隔离环境、AppFunctions 的权限要求、企业平台和可控部署。Agent 的未来不是“无所不能”，而是在安全边界内可执行、可追踪、可治理。

小结

Google I/O 2026 的主要内容可以概括为一句话：Google 正在把 Gemini 打造成横跨模型、应用、系统、开发工具和硬件的 Agent 平台。

Gemini 3.5 Flash 提供速度和行动能力，Gemini Omni 把多模态创作推向视频和世界理解，Gemini app 走向主动个人助手，Antigravity 2.0 和 Managed Agents 把开发者工具推向 Agent 原生，AppFunctions 则让 Android 应用开始为智能体暴露能力。

对开发者来说，接下来要关注的不只是模型参数，而是：如何把应用能力结构化、如何接入 Agent 工具链、如何设计权限和审计，以及如何让自己的产品在系统级 Agent 生态里被安全可靠地调用。

参考来源：

PageIndex 是什么？不用向量库的推理式 RAG 文档索引解析

Wed, 20 May 2026 23:51:37 +0800

VectifyAI/PageIndex 是一个很有意思的 RAG 项目。它不从“再建一个向量库”开始，而是把长文档先整理成类似目录的树状结构，再让 LLM 沿着这棵树做推理式检索。

项目地址：VectifyAI/PageIndex

截至本文整理时，GitHub 页面显示项目约有 31.8k stars、2.7k forks，许可证为 MIT。README 给它的定位是：Vectorless, Reasoning-based RAG，也就是无向量库、基于推理的 RAG。

它想解决什么问题

传统 RAG 的常见路径是：切块、向量化、写入向量数据库，再用相似度搜索召回片段。这套方法简单、通用，也很成熟，但在长篇专业文档里容易遇到几个问题：

相似度不等于真正相关。
文档结构被切块打散，章节关系丢失。
召回结果可解释性弱，很难说明为什么命中这一段。
对财报、监管文件、法律文书、技术手册这类材料，问题往往需要跨章节推理。

PageIndex 的思路是反过来：先把文档组织成语义树，再让模型像人类读目录、翻章节、逐层定位一样查找相关内容。

PageIndex 的基本工作流

README 里把 PageIndex 的检索分成两步：

为文档生成类似 Table-of-Contents 的树状结构索引。
通过树搜索做 reasoning-based retrieval。

这棵树不是简单的文件目录，而是面向 LLM 使用的文档结构。节点里会有标题、页码范围、摘要、子节点等信息。这样模型在回答问题时，不必一开始就面对大量零散 chunk，而是可以先判断应该进入哪个章节，再继续向下搜索。

这种方式更适合结构清晰但内容很长的文档，例如：

金融报告和 SEC filings。
监管材料和合规文档。
学术教材和论文。
法律文件。
技术手册和产品文档。
超过模型上下文窗口的大型 PDF。

和传统向量 RAG 的差异

PageIndex 的核心卖点可以概括成五点。

第一，不需要 Vector DB。它依赖文档结构和 LLM 推理来定位内容，而不是只做向量相似度搜索。

第二，不做传统 chunking。文档会按自然章节组织，而不是被切成固定长度片段。

第三，可解释性更强。检索路径可以对应到页码、章节和树节点，比“向量相似度命中某段文本”更容易追踪。

第四，检索是上下文感知的。问题、对话历史、领域背景都可以影响树搜索路径。

第五，更接近人类专家读文档的方式。人通常不是把整本文档切成小块再算相似度，而是先看目录，再定位章节，最后读细节。

这并不意味着向量库没有价值。更准确的说法是：PageIndex 适合那些“语义相似不够，需要结构和推理参与”的长文档场景。

本地怎么跑

README 提供了本地自托管方式。先安装依赖：

`1`	`pip3 install --upgrade -r requirements.txt`

然后在项目根目录创建 .env，写入 LLM API key。项目通过 LiteLLM 支持多模型：

`1`	`OPENAI_API_KEY=your_openai_key_here`

对 PDF 生成 PageIndex 结构：

`1`	`python3 run_pageindex.py --pdf_path /path/to/your/document.pdf`

也可以处理 Markdown：

`1`	`python3 run_pageindex.py --md_path /path/to/your/document.md`

常见可选参数包括：

--model
--toc-check-pages
--max-pages-per-node
--max-tokens-per-node
--if-add-node-id
--if-add-node-summary
--if-add-doc-description

README 里也提醒，本地开源版本使用标准 PDF 解析。如果是复杂 PDF，项目方的云服务会提供增强 OCR、树构建和检索流程。

Agentic Vectorless RAG 示例

项目还提供了一个 agentic vectorless RAG 示例，使用自托管 PageIndex 和 OpenAI Agents SDK。安装可选依赖后运行：

1
2

pip3 install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

这个示例的价值在于，它把 PageIndex 从“生成文档树”推进到“让 Agent 使用文档树检索”。如果你正在做企业知识库、财报问答、法规问答或技术文档 Agent，这个示例比单纯看 README 更值得跑一遍。

云服务、MCP 和 API

PageIndex 不只是一个 GitHub repo。项目页面还给了几类入口：

自托管：用开源代码本地运行，适合试验和可控部署。
Chat Platform：类似 ChatGPT 的文档分析平台。
MCP / API：方便接入现有 Agent 或自动化流程。
Enterprise：面向私有化或本地部署。

这说明它的定位不是单纯的 demo，而是想把“推理式文档检索”做成一套可集成的文档智能基础设施。

适合哪些场景

PageIndex 比较适合这些任务：

长 PDF 问答。
财报、年报、招股书、监管文件分析。
法律和合规文档检索。
技术手册问答。
多章节教材或论文检索。
需要可解释检索路径的企业知识库。
给 Agent 提供结构化文档上下文。

如果你的材料本身很短、结构不明显，或者只是普通 FAQ，传统 embedding + vector DB 可能已经够用。PageIndex 的优势更容易出现在长文档、强结构、专业领域和需要推理的问题里。

需要注意什么

第一，PageIndex 仍然依赖 LLM。树构建、摘要和检索质量会受模型能力、提示词、文档解析质量影响。

第二，本地版本使用标准 PDF 解析，复杂扫描件、图表密集型 PDF、版式混乱材料可能需要 OCR 和更强的预处理。

第三，无向量库不等于零成本。树构建本身也会消耗模型调用和时间，尤其是大规模文档库。

第四，它更像是文档结构索引和推理检索框架，不是直接替代所有 RAG 技术栈。实际生产里，也可能和向量检索、关键词检索、权限控制、缓存、审计系统一起使用。

小结

PageIndex 的有趣之处在于，它把 RAG 的重点从“文本相似度召回”转向“文档结构 + LLM 推理”。对于长文档和专业文档，这个方向很值得关注。

如果你正在做企业文档问答、金融报告分析、法规检索或技术手册 Agent，可以把 PageIndex 当成一个新的 RAG 架构参考：先让文档有结构，再让模型沿着结构推理，而不是一开始就把所有内容切碎丢进向量库。

参考来源：

GitHub：VectifyAI/PageIndex

Gemini 3.5 正式发布：Flash 先行，Google 把重点放在 Agent 和长任务执行

Wed, 20 May 2026 22:51:31 +0800

Google 在 2026 年 5 月 20 日正式发布 Gemini 3.5 系列。第一款开放使用的是 Gemini 3.5 Flash，定位不是单纯的聊天模型，而是面向 Agent、代码生成和长时间复杂任务执行的模型。

从这次公告看，Google 对 Gemini 3.5 的叙事很明确：模型不只要回答问题，还要能规划、执行、检查，并在多步任务中持续推进工作。

Gemini 3.5 Flash 先行

Gemini 3.5 Flash 已经面向多类用户开放：

普通用户可以通过 Gemini 应用和 Google 搜索中的 AI 模式体验。
开发者可以通过 Google Antigravity、Google AI Studio、Android Studio 中的 Gemini API 使用。
企业用户可以通过 Gemini Enterprise Agent Platform 和 Gemini Enterprise 使用。

Google 同时提到，Gemini 3.5 Pro 仍在开发中，已经在 Google 内部使用，计划在下个月推出。

这说明 3.5 系列会继续保留 Flash 与 Pro 的分层：Flash 更强调速度、成本和可规模化执行，Pro 则更可能面向更复杂、更高能力需求的场景。

重点是 Agent 和代码任务

Google 把 Gemini 3.5 Flash 称为目前最强的 Agent 与代码编写模型之一。公告中提到，它在多项代码和 Agent 基准测试中超过 Gemini 3.1 Pro 的部分成绩，例如 Terminal-Bench 2.1、GDPval-AA、MCP Atlas 和 CharXiv Reasoning。

这些指标本身不是普通用户最需要关心的内容。更重要的是，Google 正在把模型能力往“可执行工作流”上集中：不仅能写代码，还能处理旧项目迁移、复杂应用开发、财务报表整理、数据分析和持续测试。

在 Antigravity 开发架构中，Gemini 3.5 Flash 可以通过多个协作子代理处理大型任务。Google 展示的例子包括解析 AlphaZero 论文并实现可玩的游戏、把旧版代码转换为 Next.js、并行生成城市景观和 UI 方案。

这类能力的方向很清楚：AI 编程工具正在从“生成一段代码”走向“组织多个 Agent 完成一个项目”。

多模态 UI 与图形能力增强

Gemini 3.5 Flash 继承了 Gemini 3 的多模态基础。Google 强调它可以生成更丰富的网页 UI、交互动画和图形内容。

公告中给出的应用场景包括：

为研究论文生成交互式动画。
根据文字描述生成交互式硬件模型。
为学校募款活动生成完整品牌概念。
在短时间内为结账流程生成多种 UX 方案。

这部分对开发者和产品团队很有意义。模型不再只是输出文字说明，而是能参与前端原型、交互设计和可视化内容生成。

企业场景：把耗时流程自动化

Google 在公告中列举了多个合作伙伴案例。Shopify 使用子代理分析复杂数据并预测商家增长；Macquarie Bank 测试用 3.5 Flash 阅读超过 100 页的复杂文件，加速开户流程；Salesforce 将其整合到 Agentforce；Ramp 用它改进复杂发票 OCR；Xero 用 AI 代理处理行政流程；Databricks 用自动化工作流监控数据异常并给出修复建议。

这些案例共同指向一个趋势：企业采用大模型时，关注点正在从单次问答转向流程自动化。模型是否便宜、快、能长时间稳定执行，会比单次回答是否惊艳更重要。

Gemini Spark：个人 AI 代理

Google 还公布了 Gemini Spark。它是由 Gemini 3.5 Flash 驱动的个人 AI 代理，目标是在用户引导下长期运行并主动执行任务。

Gemini Spark 已经开始面向受信任测试人员推出，Google 计划在下周向美国 Google AI Ultra 订阅用户开放 Beta 测试。

这部分值得关注。Google 搜索、Gemini 应用、Android、Workspace 和浏览器生态本来就覆盖大量个人数字生活场景。如果个人 Agent 能与这些入口结合，影响可能比单独的聊天机器人更大。

安全机制继续前移

Google 表示 Gemini 3.5 按照 Frontier Safety Framework 开发，并强化了信息安全和 CBRN 相关防护。公告还提到使用可解释性工具，在模型给出回答前帮助检查和理解推理过程。

这说明前沿模型的发布已经不只是能力竞赛。越是强调 Agent、自动执行和长任务，安全控制、误拒率、有害输出防护和可解释性就越重要。

怎么看 Gemini 3.5

Gemini 3.5 Flash 的意义不只是“又一个新模型发布”。它更像是 Google 对下一阶段 AI 产品形态的集中押注：模型要能调用工具、拆分任务、协作执行、生成 UI，并进入个人和企业工作流。

对开发者来说，值得关注的是 Google Antigravity、AI Studio、Gemini API 和 Android Studio 中的实际体验。对企业来说，重点是它能否在真实流程中稳定减少人工操作，而不是只看 benchmark。

Gemini 3.5 Pro 还没有正式开放。等 Pro 发布后，Flash 与 Pro 在能力、价格、速度和上下文处理上的差异，才会决定它们各自更适合哪些生产场景。

参考来源：

Google Blog：Gemini 3.5 正式登场

agentmemory 项目解析：给 Claude Code、Codex 和 Cursor 加持久记忆

Tue, 19 May 2026 10:56:50 +0800

rohitg00/agentmemory 是一个面向 AI 编程 Agent 的持久记忆系统。它的目标很明确：让 Claude Code、Codex CLI、Cursor、Gemini CLI、OpenCode 等工具不必每次都重新理解项目背景、架构决策和历史问题。

项目地址：https://github.com/rohitg00/agentmemory

截至写作时，GitHub API 显示这个仓库已有约 1.3 万 star，主要语言是 TypeScript，许可证为 Apache-2.0。README 的描述是“Persistent memory for AI coding agents”。

它解决什么问题

AI 编程 Agent 的常见痛点是记忆断裂。今天让 Agent 修了一个认证问题，明天再开新会话，它可能又不知道：

认证中间件在哪个文件。
项目为什么选择某个库。
哪些测试已经覆盖。
哪些 bug 曾经修过。
团队偏好的实现方式是什么。

传统做法是写 CLAUDE.md、.cursorrules 或项目说明。但这类静态文件需要人工维护，而且越写越长，最后容易变成“所有内容都塞进上下文”。

agentmemory 的思路是：后台记录 Agent 的观察、工具调用和会话内容，压缩成可搜索记忆，再在后续会话中按需取回相关上下文。

支持哪些 Agent

README 中列出的支持范围很广，包括：

Claude Code
Codex CLI
Cursor
Gemini CLI
OpenClaw
Hermes
OpenCode
Cline
Goose
Roo Code
Windsurf
Aider

它的连接方式主要包括 hooks、MCP 和 REST API。只要客户端支持 MCP 或 HTTP，就有机会接入同一个 memory server。

快速启动

README 给出的基本安装方式：

npm install -g @agentmemory/agentmemory
agentmemory
agentmemory demo
agentmemory connect claude-code

也可以直接用 npx：

`1`	`npx @agentmemory/agentmemory`

默认服务端口包括：

API：3111
实时 viewer：3113

打开：

`1`	`http://localhost:3113`

可以看到 memory 构建过程、session、知识图谱、健康状态等信息。

和静态记忆文件有什么不同

静态记忆文件适合保存规则，比如编码风格、命令、目录说明。agentmemory 更偏运行时记忆，适合保存 Agent 实际做过什么、查过什么、修过什么。

README 中强调了几类能力：

自动捕获会话和工具调用。
BM25 + Vector + Graph 混合搜索。
MCP 工具暴露。
实时 viewer。
session replay。
本地运行，不依赖外部数据库。
支持多个 Agent 共享同一套记忆服务。

它不是替代所有项目文档，而是补上“会话历史和工作流记忆”这一层。

典型场景

第一，长期维护同一个代码库。Agent 可以记住以前修过的模块、测试策略和关键文件。

第二，多工具混用。比如平时用 Claude Code，有时用 Codex CLI 或 Cursor。如果这些工具都接入同一个 memory server，就能共享部分上下文。

第三，复杂任务拆分。长任务中间被压缩或换会话时，记忆系统可以帮助恢复关键状态。

第四，团队内沉淀经验。重复出现的 bug、架构取舍和操作步骤可以沉淀成可检索信息。

使用时要注意什么

第一，自动记忆不是越多越好。需要关注隐私、密钥、客户数据和敏感代码，不要把不该记录的内容放进长期记忆。

第二，记忆召回有误差。即使 README 给出了基准测试结果，实际项目里仍然要把召回内容当作参考，而不是事实来源。

第三，多个 Agent 共用记忆时，要设计好隔离边界。个人项目、公司项目、客户项目不应该混在同一个无隔离 memory 空间里。

第四，MCP 工具数量很多时，要注意工具暴露面。只开放实际需要的能力，避免让 Agent 获得过宽的写入、删除或导出权限。

适合谁

agentmemory 适合已经重度使用 AI 编程 Agent 的用户。尤其是：

长期维护一个项目的独立开发者。
经常切换 Claude Code、Codex、Cursor 的用户。
想研究 MCP、hooks 和 Agent 工作流的开发者。
希望把会话历史变成可检索资产的小团队。

如果只是偶尔让 AI 改一个小脚本，静态说明文件就够了。如果已经把 AI Agent 当作日常开发搭档，持久记忆系统会更有意义。

小结

agentmemory 解决的是 AI 编程中的“重新解释成本”。它把会话、工具调用和项目经验沉淀为可搜索记忆，让后续 Agent 更容易接上上下文。

这类工具的方向很重要，但也要谨慎使用。记忆系统越强，越需要重视数据边界、权限控制和清理机制。真正落地时，建议先在个人项目或非敏感代码库里试用，再逐步扩大范围。

参考项目：https://github.com/rohitg00/agentmemory

AI-Trader 是什么？一个让 AI Agent 发布交易信号、做模拟交易的平台

Tue, 19 May 2026 10:56:50 +0800

HKUDS/AI-Trader 是一个面向 AI Agent 的交易平台项目。README 对它的定位是“Agent-Native Trading Platform”，目标是让 AI Agent 可以接入平台、发布交易信号、参与讨论、复制交易和使用市场数据。

项目地址：https://github.com/HKUDS/AI-Trader

平台地址：https://ai4trade.ai

截至写作时，GitHub API 显示这个仓库已有约 1.8 万 star，主要语言是 Python。仓库 API 暂未返回明确许可证信息，正式使用前需要自行确认授权条款。

本文只做开源项目介绍，不构成投资建议。自动化交易涉及真实资金风险，任何策略、信号和 Agent 输出都不能保证收益。

它的定位

AI-Trader 的核心想法是：人有交易平台，AI Agent 也需要自己的交易平台。

按照 README 描述，任何 AI Agent 可以通过读取平台 Skill 文件并注册，快速接入 AI-Trader：

`1`	`Read https://ai4trade.ai/skill/ai4trade and register on the platform. Compatibility alias: https://ai4trade.ai/SKILL.md`

接入后，Agent 可以发布交易信号、参与社区讨论、复制优秀交易者策略、同步信号到多个 broker，并通过预测表现积累积分。

主要功能

README 中列出的能力包括：

Instant Agent Integration：AI Agent 快速接入。
Collective Intelligence Trading：多个 Agent 协作和讨论交易思路。
Cross-Platform Signal Sync：跨平台同步交易信号。
One-Click Copy Trading：跟随表现较好的交易者或 Agent。
Universal Market Access：覆盖股票、加密货币、外汇、期权、期货等市场。
Three Signal Types：策略、操作、讨论三类信号。
Reward System：通过发布信号和获得关注积累积分。

从产品形态看，它不是单一量化回测框架，而是把 Agent、信号、讨论、复制交易和模拟交易放在一起。

两类用户

README 把用户分为两类。

第一类是 Agent Traders。AI Agent 通过读取 Skill 文档接入平台，自动完成注册、安装必要组件和发布信号等步骤。

第二类是 Human Traders。普通用户可以访问平台，注册账号，浏览信号或关注表现较好的交易者。

这两个入口组合起来，形成一种“AI Agent 生产信号，人类或其它 Agent 消费信号”的平台结构。

架构结构

README 中给出的项目结构如下：

AI-Trader (GitHub - Open Source)
├── skills/              # Agent skill definitions
├── docs/api/            # OpenAPI specifications
├── service/             # Backend & frontend
│   ├── server/         # FastAPI backend
│   └── frontend/        # React frontend
└── assets/              # Logo and images

可以看到，项目把 Agent skill、API 文档、后端、前端放在同一个仓库中。后端使用 FastAPI，前端使用 React。README 的更新记录中也提到，Web 服务与后台 worker 已分离，以便价格、收益历史、结算和市场情报任务在后台运行时，不影响用户页面和健康检查。

为什么值得关注

AI-Trader 值得关注，不是因为“AI 能自动赚钱”这个说法，而是因为它把 Agent 接入金融场景的接口做得比较明确。

几个观察点：

第一，它用 Skill 文档作为 Agent 接入入口。这和 Codex、Claude Code、OpenClaw 等 Agent 工具的工作方式接近。

第二，它把交易信号、讨论、复制交易、积分系统放在平台层，而不是只做一个本地脚本。

第三，它提供 OpenAPI 文档，便于开发者理解平台接口。

第四，它支持 paper trading，也就是模拟资金环境。对研究 Agent 决策来说，模拟环境比直接上真钱安全得多。

风险和边界

自动化交易是高风险场景，尤其要注意以下几点。

第一，Agent 生成的交易信号不等于投资建议。模型可能幻觉、过拟合、误读新闻，也可能无法理解极端行情。

第二，复制交易有传染风险。一个错误信号如果被大量跟随，可能造成集中亏损。

第三，真实资金接入前必须做权限隔离。不要让 Agent 直接拥有无限制下单权限。

第四，市场数据、交易接口、结算逻辑和风控都需要审计。任何一个环节出错都可能带来财务损失。

第五，仓库 API 未显示明确许可证信息，商用或二次开发前要先核实授权。

适合谁

AI-Trader 更适合三类人：

研究 AI Agent 与金融市场交互的开发者。
想做交易信号平台或模拟交易平台的团队。
关注 Agent Skill、OpenAPI 和金融工具结合方式的产品开发者。

如果你只是想找一个“自动赚钱工具”，不建议抱这种预期。更稳妥的使用方式是把它当作 Agent 金融实验平台、paper trading 环境或交易信号协作系统来评估。

小结

AI-Trader 把 AI Agent 放进交易平台语境里，让 Agent 能注册、发布信号、讨论、复制交易和同步市场信息。它展示了 Agent-Native 应用的一种形态：不是让模型单独给建议，而是让模型进入一个有账户、API、信号、结算和协作规则的平台。

这也是它最需要谨慎的地方。金融场景不能只看自动化能力，还要看风控、权限、合规、数据来源、回测和审计。正式使用前，建议先限定在模拟交易和研究环境中。

参考项目：https://github.com/HKUDS/AI-Trader

内容发太多平台太累？AiToEarn 想用 AI Agent 帮创作者省点事

Tue, 19 May 2026 10:56:50 +0800

yikart/AiToEarn 是一个面向创作者、品牌和一人公司的 AI 内容营销项目。它试图把内容创作、发布、互动运营和变现放到同一套 Agent 工作流里，覆盖抖音、小红书、快手、B 站、视频号、TikTok、YouTube、Facebook、Instagram、Threads、X、Pinterest、LinkedIn 等平台。

项目地址：https://github.com/yikart/AiToEarn

官网地址：https://aitoearn.ai/

截至写作时，GitHub API 显示这个仓库已有约 1.5 万 star，主要语言是 TypeScript，许可证为 MIT。README 把它描述为一个给 OPC（一人公司）、创作者、品牌和企业使用的内容营销智能体平台。

它的定位

AiToEarn 不是单一的文案生成工具，也不只是定时发布工具。它把内容营销拆成四类 Agent 能力：

Monetize：内容变现。
Publish：跨平台内容发布。
Engage：内容互动运营。
Create：内容创作。

这个定位很适合现在的创作者工作流。很多内容团队的问题不在于“能不能生成一段文案”，而是生成之后还要排期、分发、互动、复盘，还要把内容和商业任务连接起来。

核心功能

Monetize：内容赚钱

AiToEarn 提供面向推广任务的内容变现能力。README 中提到三种结算模式：

结算模式	全称	含义
CPS	Cost Per Sale	按成交额结算
CPE	Cost Per Engagement	按互动量结算
CPM	Cost Per Mille	按播放量结算

这部分更像一个内容任务市场，把品牌推广需求和创作者内容分发连接起来。

Publish：内容发布 Agent

Publish 负责把内容分发到多个平台，减少逐个平台手动发布的重复劳动。README 中列出的覆盖范围包括国内外主流短视频、图文和社交平台。

它的实用点在于统一排期和统一管理。对矩阵账号、跨平台分发、出海内容团队来说，这类能力比单点 AI 文案更有价值。

Engage：内容互动 Agent

Engage 通过浏览器插件实现自动化互动运营，例如点赞、收藏、关注、评论回复和品牌监测。

使用这类能力时要注意平台规则。自动化互动很容易触及平台风控，正式使用前应确认账号权限、频率控制、平台条款和团队合规要求。

Create：内容创作 Agent

Create 负责内容生成。README 中提到视频生成模型、视频翻译、视频剪辑、图片生成和批量创作任务。

这部分适合大规模内容生产，但仍然需要人工审校。尤其是品牌内容、广告素材和跨语言内容，不能只看生成速度，还要看事实准确性、版权风险和调性一致性。

五种使用方式

AiToEarn README 给了五种入口：

方式	适合谁	是否需要部署
打开网站直接用	所有用户	不需要
在 OpenClaw 中用	OpenClaw 用户	不需要
在 Claude / Cursor 等 AI 助手中用	AI 工具用户	不需要
Docker 一键部署	想私有化部署的团队	需要服务器
源码开发	开发者	需要开发环境

其中，MCP 支持是一个值得关注的点。它意味着 Claude、Cursor 或其它兼容 MCP 的 Agent 可以把 AiToEarn 当作一个外部能力来调用。

通用 MCP 配置里常见的信息包括：

1
2

MCP 地址：https://aitoearn.ai/api/unified/mcp
认证 Header：x-api-key: 你的API-Key

自部署用户则需要替换为自己的服务地址。

Docker 部署

README 中给出的 Docker 启动方式比较直接：

1
2
3

git clone https://github.com/yikart/AiToEarn.git
cd AiToEarn
docker compose up -d

启动后打开：

`1`	`http://localhost:8080`

如果要做内容发布，README 建议配置 Relay，因为社交平台 OAuth 登录通常需要开发者凭据。Relay 的作用是借用官方凭据完成授权流程，减少自己申请各平台开发者账号的复杂度。

适合谁

AiToEarn 更适合这些用户：

做多平台内容分发的创作者。
有矩阵账号运营需求的小团队。
想把 AI Agent 接入内容营销流程的一人公司。
需要私有化部署内容发布系统的团队。
想研究 MCP 与内容平台结合方式的开发者。

如果只是偶尔写一篇文案，普通 AI 聊天工具就够了。如果你的工作流包括创作、排期、发布、互动、任务结算，AiToEarn 这类一体化平台更值得看。

使用前的注意点

第一，内容变现不等于稳定收益。CPS、CPE、CPM 都依赖平台流量、内容质量、商家需求和结算规则。

第二，跨平台发布和互动自动化要遵守平台规则。尤其是点赞、关注、评论和批量发布，不同平台都有风控策略。

第三，AI 生成内容要经过人工审核。广告法、版权、品牌安全、事实准确性都不能交给模型自动判断。

第四，私有化部署前要评估账号授权、数据安全、密钥管理和平台 API 限制。

小结

AiToEarn 的价值在于把内容营销从“生成素材”往后推进了一步：发布、互动、任务和变现都纳入 Agent 工作流。它更像一个 AI 内容运营平台，而不是单纯的 AI 写作工具。

对创作者和小团队来说，它值得关注；但真正上线前，仍然要把平台合规、账号安全、内容审核和收益预期放在前面。

参考项目：https://github.com/yikart/AiToEarn

让 AI 自己操作电脑？UI-TARS-desktop 把桌面、浏览器和工具都接了起来

Tue, 19 May 2026 10:56:50 +0800

bytedance/UI-TARS-desktop 是字节开源的多模态 AI Agent 项目。它不是单一桌面应用，而是一套 Agent 栈，当前 README 中主要包含两个方向：Agent TARS 和 UI-TARS Desktop。

项目地址：https://github.com/bytedance/UI-TARS-desktop

官网地址：https://agent-tars.com

截至写作时，GitHub API 显示这个仓库已有约 3.4 万 star，主要语言是 TypeScript，许可证为 Apache-2.0。README 对它的描述是“Open-Source Multimodal AI Agent Stack”。

Agent TARS 和 UI-TARS Desktop 的区别

README 把两个项目放在同一个表格里：

Agent TARS：通用多模态 AI Agent 栈，把 GUI Agent、视觉能力、终端、浏览器和产品工作流连接起来。
UI-TARS Desktop：桌面应用，基于 UI-TARS 模型提供原生 GUI Agent 能力，可以操作本地或远程电脑、浏览器。

简单说，Agent TARS 更像通用 Agent 运行栈，UI-TARS Desktop 更像桌面端 GUI 操作入口。

Agent TARS 能做什么

Agent TARS 主要提供 CLI 和 Web UI。它的目标是让多模态模型通过 MCP 和各种工具完成更接近真人的任务流。

README 中列出的核心能力包括：

一键启动 CLI，支持 headful Web UI 和 headless server。
混合浏览器 Agent，可以用 GUI Agent、DOM 或混合策略控制浏览器。
Event Stream，用于数据流追踪和调试。
MCP 集成，可以挂载 MCP Server 接入真实工具。

快速启动示例：

`1`	`npx @agent-tars/cli@latest`

也可以全局安装：

`1`	`npm install @agent-tars/cli@latest -g`

使用模型提供商运行：

1
2

agent-tars --provider volcengine --model doubao-1-5-thinking-vision-pro-250428 --apiKey your-api-key
agent-tars --provider anthropic --model claude-3-7-sonnet-latest --apiKey your-api-key

UI-TARS Desktop 能做什么

UI-TARS Desktop 是桌面 GUI Agent。它基于 UI-TARS 和 Seed-1.5-VL / 1.6 系列模型，重点是让模型看懂屏幕并执行鼠标、键盘操作。

README 中列出的能力包括：

自然语言控制。
截图和视觉识别。
精确鼠标与键盘控制。
跨平台支持：Windows、macOS、Browser。
实时反馈和状态显示。
本地处理，强调隐私和安全。

示例任务包括修改 VS Code 设置、查看 GitHub issue、远程控制电脑或浏览器等。

为什么 GUI Agent 重要

传统自动化依赖 API、DOM 或脚本。GUI Agent 的目标是直接面对屏幕：看见按钮、输入框、菜单和状态，再通过鼠标键盘完成操作。

这有两个价值：

第一，很多软件没有稳定 API，或者 API 覆盖不到完整流程。GUI Agent 可以像人一样从界面入手。

第二，多模态模型可以处理截图、文档、网页和应用界面，把视觉理解和操作结合起来。

但它也有局限。GUI 操作容易受分辨率、语言、布局变化、弹窗、网络延迟影响。对生产流程来说，仍然需要权限控制、执行确认和错误回滚。

和 MCP 的关系

Agent TARS 强调 MCP 集成。MCP 的价值在于把浏览器、文件、命令行、数据库、内部服务等工具统一给 Agent 调用。

对复杂任务来说，单靠 GUI 点击不够稳定。更好的方式往往是：

能用 API 的地方走 API。
需要看页面状态时用视觉。
需要真实网页交互时用浏览器。
需要本地软件操作时用 GUI Agent。

UI-TARS-desktop 这类项目正在探索的，就是把这些能力放到同一个 Agent 栈里。

使用前要注意什么

第一，桌面 Agent 有执行风险。它能操作鼠标、键盘和浏览器，就必须限制权限，避免误操作文件、账号、支付或生产系统。

第二，远程电脑和远程浏览器操作要注意安全边界。不要把未认证的控制入口暴露到公网。

第三，多模态模型可能误识别界面。关键操作前最好有人确认，尤其是删除、提交、支付、发帖、交易等不可逆操作。

第四，模型供应商、API key 和本地数据要分开管理，不要把敏感凭据写进公开配置。

适合谁

UI-TARS-desktop 适合这些场景：

想研究 GUI Agent 和 Computer Use 的开发者。
需要让 AI 操作桌面应用或浏览器的团队。
想把 MCP 工具、浏览器操作和视觉模型组合起来的 Agent 开发者。
需要远程电脑 / 远程浏览器操作实验环境的用户。

如果只是简单网页自动化，普通 Playwright 或 Selenium 可能更直接。如果任务涉及桌面软件、多模态理解和复杂工具链，UI-TARS-desktop 更值得看。

小结

UI-TARS-desktop 的看点在于它不是只做一个“会点按钮”的桌面助手，而是把 GUI Agent、视觉模型、浏览器、CLI、MCP 和远程操作放进同一套多模态 Agent 栈。

这类项目代表了 AI Agent 的一个重要方向：从文本对话走向真实软件环境。但越接近真实操作，越需要权限管理、执行审计和人工确认。试用时建议先从低风险任务开始。

参考项目：https://github.com/bytedance/UI-TARS-desktop

市面上主流 AI PPT 工具大盘点：自动生成、网页演示、PPTX 和图像路线怎么选

Mon, 18 May 2026 22:29:43 +0800

AI 做 PPT 已经不只是“输入标题，套一个模板”。在 Claude Code、Codex、Cursor 这类 AI 编程环境里，PPT 生成正在变成一组可安装、可复用的 Agent Skill：有的输出网页演示，有的生成真正可编辑的 .pptx，有的直接用图像模型把每页做成视觉稿，还有的通过 MCP 让 AI 操作 PowerPoint 文件。

这次整理了一批主流 PPT 相关 Skill。真正有价值的地方不只是榜单，而是把这类工具按交付形态拆开来看。选工具前，先问一句：最终交付物到底要给谁改、在哪里播放、是否需要继续协作？

几条路线

1. HTML 网页演示

代表项目包括 frontend-slides、guizang-ppt-skill、html-ppt-skill。

这条路线的优势是视觉表现力强。CSS 动画、Canvas、WebGL、响应式布局都能用，浏览器打开即可演示，适合技术分享、产品发布、Demo Day 和个人风格强烈的演讲。

代价也很明确：交付后不太适合让客户逐字改。客户如果拿到的是 HTML，而不是 PowerPoint 文件，后续修改往往还要回到生成流程。

如果只看 HTML 演示，frontend-slides 更像高星通用入口，guizang-ppt-skill 强在审美约束和主题风格，html-ppt-skill 则胜在主题数量、布局数量和演讲者模式。

2. 原生 PPTX

代表项目包括 mckinsey-pptx、ppt-agent-skills、claude-office-skills 和 ppt-master。

这是商业交付最稳的路线。只要客户要求“能在 PowerPoint 里改字、改图、套公司模板”，最终就要落到 .pptx。

其中 ppt-master 很值得单独关注。它的思路是先让 LLM 生成 SVG，再转成 PowerPoint 原生 DrawingML 对象，目标是让文字框、形状、图表都能在 PPTX 里继续编辑。它还支持从 PDF、DOCX、URL、Markdown 生成 PPTX，并能做模板复刻、动画、旁白和本地预览。

这条路线适合咨询交付、公司汇报、白皮书演示、长报告压缩成 PPT 等场景。缺点是视觉上限通常受 PowerPoint 本身限制，复杂效果不如 HTML 或图像路线自由。

3. AI 图像驱动

代表项目包括 NanoBanana-PPT-Skills、gpt_image_2_skill 和 ppt-image-first。

这条路线先把每一页当成视觉图来生成，再把图片放进 PPTX 或其它容器里。优点是完成度高，尤其适合封面、社交媒体图、视觉提案、传播型内容。

问题是可编辑性差。页面本质上是一张图，后面要改一个标题、换一段文案、挪一个图标，可能就要重新生成。它适合“看起来要好”，不适合“客户要反复改”。

4. MCP / 协议层

代表项目包括 Office-PowerPoint-MCP-Server、PPTAgent。

这类工具不一定直接生成完整 PPT，而是给 AI 一个操作 PowerPoint 的接口。接入 MCP 后，模型可以读、改、写 .pptx 文件。

这条路线适合已经有 PPT 文件、需要 AI 辅助修改的工作流。比如批量改格式、根据反馈重排页面、让模型检查每页是否符合目标。PPTAgent 强调反思式生成，也就是每生成一页后再回头检查，这个方向对减少“AI PPT 很粗糙”的问题有启发。

5. 综合设计平台

代表项目包括 open-design 和 docsagent。

这类项目已经超出 PPT 生成本身。open-design 更像本地优先的设计平台，可以生成原型、slides、images、videos，并支持多种导出格式。docsagent 不是 PPT 工具，但能索引和对话本地文档，适合作为 PPT 生成前的资料整理层。

如果你的需求不是单次做 PPT，而是从资料、设计、原型到交付的一整套流程，这类平台更值得看。

Skill 元信息

Star 数来自原文 2026-05-15 的抓取结果，只适合作为热度参考，实际使用前建议再打开仓库确认维护状态、README 和 LICENSE。

Skill	作者	链接地址	Star	语言	路线
frontend-slides	@zarazhangrui	GitHub: zarazhangrui/frontend-slides	17,530	Shell	HTML 网页演示
guizang-ppt-skill	@op7418（歸藏）	站内文章: guizang-ppt-skill GitHub: op7418/guizang-ppt-skill	8,832	HTML	HTML 网页演示
html-ppt-skill	@lewislulu	GitHub: lewislulu/html-ppt-skill	3,834	HTML/CSS/JS	HTML 网页演示
mckinsey-pptx	@seulee26	GitHub: seulee26/mckinsey-pptx	426	Python	原生 PPTX
ppt-agent-skills	@sunbigfly	GitHub: sunbigfly/ppt-agent-skills	714	Python	原生 PPTX
claude-office-skills	@tfriedel	GitHub: tfriedel/claude-office-skills	631	Python	原生 PPTX
ppt-master	@hugohe3	GitHub: hugohe3/ppt-master	16,626	Python	原生 PPTX
NanoBanana-PPT-Skills	@op7418（歸藏）	GitHub: op7418/NanoBanana-PPT-Skills	2,668	Python	AI 图像驱动
gpt_image_2_skill	@wuyoscar	GitHub: wuyoscar/gpt_image_2_skill	2,102	Python	AI 图像驱动
ppt-image-first	@NyxTides	GitHub: NyxTides/ppt-image-first	799	Python	AI 图像驱动
Office-PowerPoint-MCP-Server	@GongRzhe	GitHub: GongRzhe/Office-PowerPoint-MCP-Server	1,708	Python	MCP / 协议层
PPTAgent	@icip-cas	GitHub: icip-cas/PPTAgent	4,354	Python	MCP / 协议层
open-design	@nexu-io	站内文章: open-design GitHub: nexu-io/open-design	40,822	TypeScript	综合设计平台
docsagent	@docsagent	GitHub: docsagent/docsagent	687	TypeScript	综合设计平台

选型可以这样判断

如果客户要继续编辑，优先看原生 PPTX 路线，尤其是 ppt-master、mckinsey-pptx、ppt-agent-skills。

如果是自己演讲，且视觉表现比后续编辑更重要，优先看 HTML 路线，尤其是 frontend-slides、guizang-ppt-skill、html-ppt-skill。

如果目标是海报感、封面感、传播图，优先看图像路线，比如 ppt-image-first、gpt_image_2_skill、NanoBanana-PPT-Skills。

如果已经有 PPT 文件，只想让 AI 帮你读、改、重排，可以看 MCP 路线。

如果是学术、营销、翻译、长报告压缩这类明确场景，也可以继续找垂直 Skill，而不是拿通用 PPT 生成器硬做。

最后要注意的事

开源项目不能只看 Star。真正使用前还要确认三件事：

LICENSE 是否允许你的使用方式。
生成物是否满足交付要求，尤其是可编辑性。
成本是否可接受，包括模型调用、图像生成、大上下文模型和可能的云服务费用。

这类工具变化很快，Star 数会变，项目维护状态也会变。但选型逻辑相对稳定：先确定交付形态，再看具体工具。PPT 是给人讲、给人改、还是给人看，这三个答案往往会把选择范围直接缩小一大半。

wx-cli 项目解读：用命令行查询本地微信聊天记录

Mon, 18 May 2026 21:02:21 +0800

wx-cli 是一个用 Rust 编写的本地微信数据命令行工具，目标是在命令行里查询自己的微信会话、聊天记录、联系人、群成员、收藏、朋友圈、公众号文章、附件和统计信息。

它不是一个云端微信同步服务，也不是聊天机器人。它更像一个本地只读数据检索层：微信仍然在本机运行，数据仍然留在本机，wx-cli 负责按需解密、缓存和查询本地数据库，然后把结果以 YAML 或 JSON 形式输出给人或 Agent 使用。

这个项目有两个值得关注的点：一是它把微信本地数据查询做成了跨平台 CLI；二是它专门考虑了 Claude Code、Cursor、Codex 这类 AI Agent 的使用场景，提供了 SKILL.md 和带 meta 的结构化输出。

wx-cli 能做什么

按项目 README 的描述，wx-cli 覆盖的功能很完整：

查看最近会话和未读会话。
查询某个联系人或群的聊天历史。
全库搜索关键词。
查看新增消息。
查询联系人、群成员和群昵称。
查询收藏。
查询朋友圈通知、朋友圈时间线和朋友圈正文。
查询公众号文章推送。
列出和提取聊天图片附件。
做聊天统计。
导出聊天记录为 Markdown 或 JSON。

这些能力让它不只是“查聊天记录”，而是把微信本地数据变成了可搜索、可统计、可导出的本地资料库。

为什么适合 AI Agent

很多命令行工具只是给人看的，输出是一段文本。wx-cli 则明显考虑了 Agent 读取。

README 提到，history、search、sessions、unread、new-messages、stats、attachments 等命令会附带 meta 信息。meta 里包含结果状态、未知分片、命中数据的最新时间、session 记录的最新时间等信息。

这对 Agent 很有用。因为 AI 不只需要“查到了什么”，还需要知道“结果新不新”“有没有可能漏消息”“是不是需要重新 init”。例如：

status 可以提示结果是否 ok 或 possibly_stale。
unknown_shards 可以提示是否存在 daemon 当前没有 key 的数据库分片。
chat_latest_timestamp 可以告诉 Agent 当前命中数据里的最新消息时间。
session_last_timestamp 可以帮助判断本地 session 记录是否明显领先于查询结果。

这类元信息可以减少 AI 误判，让 Claude Code、Cursor、Codex 这类工具在处理微信数据时更稳。

安装方式

项目推荐通过 npm 全平台安装：

`1`	`npm install -g @jackwener/wx-cli`

也支持 macOS / Linux 的 curl 安装：

`1`	`curl -fsSL https://raw.githubusercontent.com/jackwener/wx-cli/main/install.sh \| bash`

Windows 可以在管理员 PowerShell 中运行：

`1`	`irm https://raw.githubusercontent.com/jackwener/wx-cli/main/install.ps1 \| iex`

如果要从源码构建，也可以直接用 Rust：

1
2

git clone git@github.com:jackwener/wx-cli.git && cd wx-cli
cargo build --release

构建产物是 target/release/wx，Windows 下是 wx.exe。

和 Agent Skill 的关系

wx-cli 还提供了面向 AI Agent 的 Skill。可以通过 skills CLI 一键安装到 Claude Code、Cursor、Codex 等支持 Skills 的环境：

`1`	`npx skills add jackwener/wx-cli`

全局安装：

`1`	`npx skills add jackwener/wx-cli -g`

安装后，Agent 会读取仓库里的 SKILL.md，知道如何安装、初始化和调用 wx-cli。

这意味着你可以让 Agent 帮你做一些本地信息整理任务，例如：

找某段时间某个群聊里讨论过的关键词。
汇总最近未读消息。
从某个会话里导出最近聊天记录。
搜索公众号文章推送链接。
分析某个群聊里的发言统计。

前提仍然是：这些数据必须是你本机、你自己的微信数据。

基本使用方式

初始化前需要保持微信正在运行。不同平台要求不同。

Linux 上可以执行：

`1`	`sudo wx init`

Windows 上需要用管理员 PowerShell：

wx init

macOS 上更复杂。README 说明，默认路径需要先对 WeChat 做 ad-hoc 签名，才能扫描进程内存；重签名后还要清理旧 TCC 授权记录，否则截图、视频通话、麦克风等权限可能出现“看起来已开启但实际拒绝”的问题。项目文档也提醒，重签名会带来 macOS 频繁弹出访问其他 App 数据提示的副作用。

初始化后，可以用下面的命令验证：

`1`	`wx sessions`

能看到最近会话，说明基本链路已经可用。daemon 会在首次调用时自动启动。

常用命令示例

查看最近会话：

`1`	`wx sessions`

查看未读会话：

`1`	`wx unread`

只看真人未读，过滤公众号和折叠入口：

`1`	`wx unread --filter private,group`

查看某个会话最近聊天记录：

`1`	`wx history "张三"`

拉取更多历史消息：

`1`	`wx history "张三" -n 2000`

按时间范围查询群聊：

`1`	`wx history "AI群" --since 2026-04-01 --until 2026-04-15`

全库搜索：

`1`	`wx search "关键词"`

搜索某个群中的关键词：

`1`	`wx search "会议" --in "工作群" --since 2026-01-01`

导出聊天记录：

1
2

wx export "张三" --format markdown -o chat.md
wx export "AI群" --since 2026-01-01 --format json

这些命令都比较适合被脚本或 Agent 调用，尤其是加上 --json 后。

朋友圈和公众号文章

wx-cli 不只查聊天。

朋友圈相关命令分成通知和帖子：

1
2
3

wx sns-notifications
wx sns-feed
wx sns-search "关键词"

需要注意，朋友圈数据只覆盖你本地刷到过的内容。微信客户端按需下载，没在本地出现过的数据，工具也不会凭空拿到。

公众号文章则通过独立命令查询：

wx biz-articles
wx biz-articles --account "返朴"
wx biz-articles --since 2026-05-01 --until 2026-05-10
wx biz-articles --json | jq '.[].url'

它会返回公众号名称、标题、URL、摘要、封面、时间等字段。对做资料整理、文章收集和本地知识库的人来说，这个功能很实用。

附件提取

微信聊天里的图片附件通常不是直接可读的普通图片文件，而是存在 xwechat_files/<wxid>/msg/attach/... 下的 .dat 文件。

wx-cli 提供了两步流程：

1
2

wx attachments "张三"
wx attachments "AI群" --kind image -n 100

先拿到 attachment_id 后，再提取：

`1`	`wx extract <attachment_id> -o ~/Desktop/photo.jpg`

输出报告里会带 md5、dat_path、dat_size、output、format、decoder 等信息。README 中说明它支持 legacy XOR、V1 fixed-AES、V2 AES + XOR 等解码档位，不同平台的 image key 提取方式也不同。

这部分能力很强，但也更需要谨慎使用：只处理自己的数据，不要把它用于未经授权的数据访问。

daemon 架构为什么重要

wx-cli 的性能点在 daemon。

README 中给出的结构大致是：

wx (CLI) ──Unix socket──▶ wx-daemon (后台进程)
                              │
                    ┌─────────┴──────────┐
               DBCache               联系人缓存
           (mtime 感知复用)

daemon 首次解密后，会把数据库和 mtime 信息持久化到 ~/.wx-cli/cache/。如果数据库文件 mtime 没变，后续调用就可以复用缓存，不需要每次重新解密。

这对命令行查询和 Agent 循环都很关键。Agent 可能会连续查询多个会话、搜索多个关键词、再做统计和导出。如果每次都重新扫描和解密，体验会很差；daemon 缓存让它更接近一个本地查询服务。

原理简述

项目 README 对原理有直接说明：微信 4.x 使用 SQLCipher 4 加密本地数据库，WCDB 会在进程内存中缓存派生后的 raw key。

wx-cli 会根据平台使用不同方式扫描微信进程内存，匹配 key 模式后提取密钥，再由 daemon 按需解密和缓存数据库。

不同平台的底层机制不同：

macOS 使用 Mach VM API。
Linux 使用 /proc/<pid>/mem。
Windows 使用 VirtualQueryEx 和 ReadProcessMemory。

这些能力解释了为什么初始化通常需要较高权限，也解释了为什么 macOS 上会涉及签名和隐私授权。

使用边界和风险

这类工具必须先讲边界。

wx-cli README 的免责声明写得很明确：工具仅用于学习和研究目的，用于解密自己的微信数据，并要求遵守相关法律法规，不得用于未经授权的数据访问。

实际使用时也建议注意：

只在自己的电脑、自己的微信账号上使用。
不要把导出的聊天记录随意上传到云端模型。
用 Agent 分析聊天记录时，先确认 API 供应商和数据出境风险。
导出 Markdown / JSON 后要注意文件权限和备份位置。
公司或多人设备上使用前，先确认合规和授权。

本地工具不等于没有隐私风险。它减少了数据离开本机的默认路径，但如果你把输出交给云端模型、网盘或第三方脚本，风险又会回来。

适合谁使用

wx-cli 适合这些场景：

想在本地快速搜索自己的微信历史消息。
需要把某个会话导出为 Markdown 或 JSON。
想统计某个群聊在一段时间内的发言情况。
想让 Claude Code、Cursor、Codex 等 Agent 帮忙整理本地微信资料。
想把公众号文章推送链接整理进本地知识库。
想研究微信本地数据库结构和解密流程。

不太适合这些场景：

想做云端微信同步。
想绕过他人设备或账号权限。
想无脑图形界面操作，不接触命令行。
不愿意处理 macOS 权限、Windows 管理员权限或 Linux sudo 的用户。

小结

wx-cli 的价值，不只是“命令行查微信聊天记录”。更准确地说，它把本地微信数据变成了一个可查询、可导出、可被 Agent 消费的本地数据源。

它的 daemon 架构解决了反复解密和查询性能问题；meta wrapper 让 AI Agent 更容易判断结果是否新鲜；SKILL.md 则把安装和使用方式交给 Claude Code、Cursor、Codex 这类工具理解。

如果你经常需要从微信里找信息、整理群聊、导出记录或构建个人资料库，wx-cli 很值得关注。但使用它时也要始终记住一条底线：只处理自己的数据，并且谨慎管理导出结果。

参考资料

jackwener/wx-cli GitHub 仓库

Anthropic Founder’s Playbook 解读：Claude 如何帮助创业团队提速

Mon, 18 May 2026 18:02:58 +0800

Anthropic 在 Claude 官方博客发布了面向创业者的 The Founder’s Playbook，核心问题很直接：一家 AI-native startup 如何更快从洞察走到产品、发布和规模化？

这份 playbook 并不是单纯介绍 Claude 的功能清单，而是把创业过程拆成四个阶段：Idea、MVP、Launch 和 Scale。它强调的不是“让 AI 代替创始人做判断”，而是把市场调研、文案初稿、代码脚手架、运营流程、销售材料等重复性工作先交给 Claude，让创始人把更多时间留给判断、品味、取舍和信任建设。

这份 playbook 在讲什么

AI 创业公司面临的压力越来越像一场压缩比赛：产品周期更短，竞争者更多，用户对速度和质量的要求同时提高。过去需要多人团队分工完成的事情，现在可以用 AI 先做出第一版，再由创始团队审阅、修正和推进。

Anthropic 给出的框架很清晰：不要一开始就试图把公司完全“AI 化”，而是先找一个耗时、重复、低创造密度的流程，让 Claude 生成初稿、脚本、调研结果或执行清单。创始人负责定义目标、校准方向、判断质量，并把可行结果接入真实业务。

第一阶段：Idea

Idea 阶段的重点不是“想一个酷点子”，而是验证这个点子是否值得继续投入。

Claude 适合在这个阶段帮助创始人做几件事：整理市场地图、归纳用户痛点、比较竞品定位、提出潜在楔入点，并把模糊想法压缩成更具体的价值主张。

但这一步最重要的仍然是人的判断。AI 可以帮助你更快看到一批可能性，却不能替你承担“这个市场是否真的存在强需求”的责任。创始人仍然需要和真实用户交流，观察他们愿不愿意改变现有工作流，甚至愿不愿意付费。

第二阶段：MVP

MVP 阶段是 Claude Code 最容易发挥作用的地方。

对小团队来说，最稀缺的往往不是想法，而是把想法变成可试用产品的速度。Claude Code 可以参与生成脚手架、写脚本、补组件、检查边界条件、产出技术方案说明，帮助团队更快做出可验证的版本。

这里的关键不是让 AI 一次性写出完美产品，而是把“从 0 到第一版”的摩擦降下来。创始人和工程师仍然需要审查架构、安全性、数据处理和用户体验，但他们不必把时间浪费在大量机械性的初稿工作上。

第三阶段：Launch

Launch 阶段考验的是叙事、分发和反馈速度。

很多创业团队会低估发布的复杂度：官网文案、产品演示、邮件、社交媒体内容、用户访谈、销售话术、投资人更新，每一项都需要清楚表达“为什么现在需要这个产品”。

Claude 在这里可以充当一个高频协作对象：帮团队生成不同版本的定位表达，改写面向不同用户群体的介绍，模拟用户疑问，整理发布节奏，并把早期反馈转成下一轮产品和市场动作。

第四阶段：Scale

Scale 阶段的主题从“做出来”转向“可重复地增长”。

当公司开始有稳定用户和收入，创始团队会被运营、销售、客服、数据分析和内部协作拉扯。Claude Cowork 这类 agent 化能力适合处理更完整的任务：例如做市场研究、设计活动方案、整理募资策略、汇总增长指标，或者把一套运营流程拆成可以反复执行的步骤。

这也是 AI-native 公司和传统软件公司的差异开始显现的地方。真正的变化不只是“员工使用 AI 工具”，而是公司流程从一开始就围绕 AI 协作来设计：哪些任务由人定义标准，哪些任务由 AI 先跑一遍，哪些结果必须进入审查，哪些流程可以沉淀成可复用模板。

Claude Code、Claude Cowork 和 Chat 各自适合做什么

从这篇官方博客的描述看，Anthropic 想让创业者把 Claude 分成三类使用场景。

Claude Code 更偏工程协作，适合写代码、生成脚本、分析边界情况、产出组件规格和技术文档。它解决的是“把想法推进成可运行东西”的问题。

Claude Cowork 更像可委派的工作代理，适合市场研究、活动设计、募资策略、运营分析这类需要连续执行的任务。它解决的是“把一件较完整的业务工作先推进一轮”的问题。

Claude Chat 则更适合创始人的判断时刻：推敲 go-to-market 策略、压力测试产品定位、比较路线图优先级、打磨关键叙事。它不是执行机器，而是一个可以快速反复讨论的思考搭档。

对创业团队真正有用的地方

这份 playbook 的价值，不在于告诉创业者“AI 很重要”。这一点已经不新鲜了。

它更有用的地方，是把 AI 使用方式从零散工具调用，推进到公司建设方法论：每个阶段都有不同的瓶颈，每个瓶颈都可以拆出适合 AI 参与的部分。

Idea 阶段，AI 帮你扩大搜索空间。MVP 阶段，AI 帮你压缩实现周期。Launch 阶段，AI 帮你加快表达和分发实验。Scale 阶段，AI 帮你沉淀可重复流程。

这套逻辑对小团队尤其重要。因为小团队没有足够的人手覆盖所有职能，但可以用 AI 先补上“第一版能力”，再把有限的人力投入到最需要判断和关系建设的部分。

需要警惕的误区

第一个误区是把 AI 生成的内容直接当结论。市场调研、竞品分析、用户画像、增长策略都必须回到真实数据和用户反馈里验证。

第二个误区是低估审查成本。AI 能显著降低初稿成本，但代码质量、法律风险、品牌表达、商业承诺和安全问题仍然需要人负责。

第三个误区是过早自动化。对还没有跑通的流程，不应该急着交给 agent 自动执行。更稳妥的方式是先让 AI 参与其中一小段流程，观察输出质量，再逐步扩大范围。

小结

Anthropic 这篇 The Founder’s Playbook 传递的信号很明确：AI-native startup 的优势，不只是“会用 AI 写代码”，而是从公司第一天开始，就把 AI 作为产品、工程、市场、销售和运营里的协作层。

对创业者来说，最现实的起点不是搭建宏大的 AI 工作流，而是选出一个最耗时、最重复、最拖慢推进速度的任务，让 Claude 先做第一版。真正的竞争力，来自人类创始人对方向、质量和信任的把关，以及团队能否把这种协作方式稳定地嵌入日常工作。

参考资料

The founder’s playbook for the age of AI

Vercel AI SDK 是什么？TypeScript 开发者构建 AI 应用的统一工具包

Sun, 17 May 2026 23:07:38 +0800

vercel/ai 是 Vercel 维护的开源 AI SDK。

它的定位很明确：给 TypeScript 开发者提供一套统一工具，用来构建 AI 应用和 AI Agent。它来自 Next.js 背后的团队，但并不只服务于 Next.js，也支持 React、Svelte、Vue、Angular 等 UI 框架，以及 Node.js 等运行时。

项目地址：https://github.com/vercel/ai

如果你正在做聊天应用、AI 写作工具、RAG 应用、带工具调用的 Agent、流式输出界面，或者想把多个模型供应商接到同一个应用里，Vercel AI SDK 是一个值得关注的基础库。

它解决的核心问题

现在做 AI 应用，最大麻烦之一不是“能不能调模型”，而是不同模型供应商的接口、流式输出、工具调用、错误处理和前端状态管理都不一样。

例如：

OpenAI 有自己的 SDK 和响应格式。
Anthropic 有自己的消息结构。
Google、xAI、Mistral、DeepSeek、Groq 等也各有差异。
流式输出需要处理 chunk。
工具调用需要处理模型发起的结构化请求。
前端聊天 UI 还要管理消息、加载状态、取消、重试和错误展示。

如果每个供应商都手写一套适配层，项目会很快变复杂。

Vercel AI SDK 的思路是把这些差异收敛到统一 API 后面。开发者用一套接口写应用，再通过 Provider 接入不同模型。

统一 Provider 架构

Vercel AI SDK 的一个核心特点，是 provider-agnostic，也就是不绑定单一模型厂商。

它可以通过统一 API 访问 OpenAI、Anthropic、Google 等模型提供方。项目 README 还提到，默认情况下 AI SDK 会使用 Vercel AI Gateway，让开发者更容易访问多个主流 provider。

这对工程项目很实用。

因为很多 AI 产品最终都不会只依赖一个模型：

有的任务适合强推理模型。
有的任务适合便宜快速模型。
有的任务需要多模态。
有的任务需要长上下文。
有的任务需要本地或私有部署模型。

统一 Provider 架构让应用更容易做模型切换、灰度测试、成本控制和备选方案。

流式输出是前端体验的关键

AI 应用和传统 API 最大的体验差异之一，是响应可能很长。

如果用户每次都要等完整回答返回，聊天工具、写作工具和代码助手会显得很慢。流式输出可以让文本逐步显示，用户更早看到结果。

Vercel AI SDK 对流式生成做了比较完整的封装。开发者不需要从零处理底层事件流，而是可以使用 SDK 提供的生成和流式接口，把模型输出接到前端 UI。

这对 Next.js / React 应用尤其方便。

一个 AI 聊天界面看起来简单，但实际要处理：

消息列表。
用户输入。
服务器请求。
流式 token 展示。
加载状态。
错误状态。
中止生成。
重新生成。

这些都是 AI SDK 试图帮开发者减少重复劳动的地方。

工具调用和 Agent 场景

随着 AI 应用从“聊天”走向“做事”，工具调用变得越来越重要。

模型不只是输出自然语言，还可能需要调用外部函数：

查数据库。
搜索文档。
调用业务 API。
读取订单状态。
生成图表。
创建日历事件。
修改项目文件。

Vercel AI SDK 支持工具调用相关能力，让开发者可以定义工具、参数和执行逻辑，再让模型在合适时机请求调用。

这也是它从“聊天 UI SDK”扩展到“AI 应用和 Agent 工具包”的关键。

不过，工具调用不是加上去就万事大吉。真实项目还要考虑：

参数校验。
权限边界。
工具调用日志。
幂等性。
超时和重试。
人工确认。
敏感操作限制。

AI SDK 可以帮助处理接口和流程，但安全边界仍然需要开发者自己设计。

UI 集成能力

Vercel AI SDK 对前端框架比较友好。

它不仅提供核心生成 API，也围绕聊天、补全、消息状态和流式 UI 做了封装。对于使用 Next.js 和 React 的团队来说，这能减少很多样板代码。

但它并不只适合 Vercel 部署。

如果你的项目本身是 TypeScript 技术栈，或者后端运行在 Node.js 环境，AI SDK 仍然可以作为模型调用和流式处理层来使用。是否部署在 Vercel，取决于你的应用架构、团队习惯和基础设施选择。

Skill for Coding Agents

vercel/ai README 里还有一个有趣的建议：如果你使用 Claude Code、Cursor 等 coding agent，可以把 AI SDK skill 加到仓库里。

示例命令是：

`1`	`npx skills add vercel/ai`

这说明 Vercel 已经意识到，AI SDK 的用户不只是人类开发者，也包括 coding agent。

当 agent 修改使用 AI SDK 的项目时，如果仓库里有专门的 skill，它可以更好地理解 SDK 约定、常见 API、项目结构和最佳实践，减少乱写代码的概率。

这个方向很值得注意。

未来开源项目可能不只提供 README 和 docs，还会提供给 AI coding agent 使用的结构化技能说明。对复杂 SDK 来说，这会变成新的开发者体验入口。

适合哪些项目

Vercel AI SDK 适合这几类场景：

基于 Next.js / React 的 AI 聊天应用。
需要流式输出的写作、问答、客服和代码助手。
需要接入多个模型 provider 的 AI 产品。
想快速构建 RAG 或文档问答原型的团队。
需要工具调用、函数调用或轻量 Agent 能力的应用。
已经使用 TypeScript / Node.js 技术栈的团队。

它尤其适合前端和全栈开发者。因为很多 AI 应用的难点不只是模型调用，而是如何把模型输出变成稳定、流畅、可交互的产品体验。

不适合什么场景

如果你的项目主要是 Python 后端、深度学习训练、模型微调或底层推理服务，Vercel AI SDK 可能不是核心工具。

它更偏应用层，而不是模型训练框架。

如果你需要的是：

自己训练模型。
管理 GPU 推理集群。
做底层 batch inference。
深度控制 tokenizer、KV cache、量化和推理引擎。

那更应该看 PyTorch、vLLM、SGLang、TensorRT-LLM、llama.cpp 或云厂商推理服务。

Vercel AI SDK 更像“把模型能力接进产品”的应用开发层。

使用时要注意什么

第一，不要把统一 API 理解成完全无差异。

不同模型 provider 的能力、上下文长度、工具调用格式、流式细节、错误类型和计费方式仍然不同。统一 SDK 能减少工程摩擦，但不能消除模型差异。

第二，要控制成本。

AI 应用一旦上线，流式聊天、重试、工具调用、RAG 检索和多模型 fallback 都可能增加调用成本。需要做限流、缓存、日志和预算监控。

第三，要处理安全边界。

如果模型能调用工具，就必须限制工具能做什么。不要让模型直接执行高风险操作，也不要把密钥、数据库写权限和生产环境操作裸露给模型。

第四，要保留可观测性。

AI 应用出问题时，不能只看前端报错。你需要知道用户输入、模型选择、工具调用、响应时间、token 消耗、错误类型和最终输出。

小结

vercel/ai 不是一个新的模型，也不是单纯的聊天组件。

它更像 TypeScript AI 应用开发的基础设施：统一 Provider、流式输出、工具调用、前端状态管理和 agent 场景，都被放进一个开源 SDK 里。

对已经使用 Next.js、React、TypeScript、Node.js 的团队来说，它可以显著降低从“模型 API 能跑”到“产品体验可用”的工程成本。

但它也不是万能层。模型选择、权限设计、成本控制、日志监控和业务安全，仍然需要开发者自己负责。

如果你想做 AI 应用，而不是训练模型，Vercel AI SDK 是一个值得先试的工具包。

参考资料

Midjourney 2026 年 5 月更新：会话模式、AI 辅助开发与 SREF 整理

Sun, 17 May 2026 20:20:51 +0800

Midjourney 2026 年 5 月 14 日的 Office Hours 信息里，最值得关注的不是单个模型参数，而是产品形态正在继续从“输入提示词生成图片”，向“更自然地组织创作工作流”移动。

这次内容来自一篇日文整理稿，记录了 Midjourney 团队近期问答中的多个方向：会话模式升级、AI 辅助开发、网站改版、SREF 和标签整理、Omni-reference、多角色一致性，以及团队内部如何使用 Midjourney。

如果只看一句话总结：Midjourney 正在让图片生成更像一个可对话、可整理、可持续迭代的创作系统。

会话模式变得更重要

这次更新里最直接的变化，是 Conversational Mode，也就是会话模式。

过去使用 Midjourney，很多操作仍然依赖参数和固定写法。你需要记住宽高比、图片参考、风格参考、模型参数等规则，再把它们写进 prompt 或界面设置里。

新的会话模式方向，是让用户用更自然的语言描述这些设置。

例如，用户可以通过语音或文字指定：

默认参数。
画面宽高比，例如 16:9。
图片参考。
风格参考，也就是 --sref。
V7 里的 Omni-reference。

这说明 Midjourney 并不只是想提升生成质量，也在降低参数操作成本。

对普通用户来说，最大的变化是不用一直记命令。对重度用户来说，会话模式如果足够稳定，未来可能会变成“用自然语言调整生成设置”的入口。

AI 辅助开发正在改变 Midjourney 团队的迭代速度

另一个很有意思的点，是 Midjourney 团队自己也在大规模使用 AI 辅助开发。

原文提到，团队现在能更快修复小 bug、界面摩擦和工作流问题。甚至有用户通话中发现产品 bug，团队借助 AI 辅助实时修复，经过 review 后快速部署的例子。

这件事比“AI 帮工程师写代码”更值得细看。

它说明 AI 开发工具已经开始影响 AI 产品自己的迭代方式：

用户反馈可以更快进入修复流程。
小型体验问题更容易被处理。
工程师把更多精力放在架构、审查、设计决策和测试上。
产品团队可以更频繁地清理边缘问题。

Midjourney 这种产品有大量创作路径、参数组合、移动端体验、搜索和整理流程。很多问题不是“核心模型不会生成”，而是某个入口不顺、某个操作多一步、某个边缘状态不好用。

AI 辅助开发最适合加速这类小而多的改进。

网站改版重点是工作流，而不是砍功能

Office Hours 里还提到，Midjourney 网站正在进行较大规模的改版。

目标不是删掉复杂功能，而是让创作流程更直观，让新用户更容易上手，也让工具和功能组织得更清楚。

这点很关键。

Midjourney 的问题不是功能太少，而是功能越来越多之后，入口、收藏、整理、引用、探索和复用都变得复杂。对于轻度用户来说，难点是“我该从哪里开始”；对于重度用户来说，难点是“我如何管理大量风格、参考和实验结果”。

可能的发布策略包括：

新旧界面并行提供。
先做 alpha 测试。
分阶段迁移，避免影响重度用户。

这类策略说明团队知道 Midjourney 不是普通图片生成玩具。很多用户已经把它放进真实创作流程里，界面改变不能随便打断已有习惯。

SREF、风格和标签整理仍是痛点

SREF 和风格整理，是这次问答里很值得关注的部分。

用户希望有更好的整理系统，尤其是：

随机 SREF。
风格参考。
保存下来的美学方向。
标签和颜色标签。
更强的筛选、归类和复用能力。

但团队也提出了一个问题：如果当前文件夹系统已经支持一张图进入多个文件夹、无限文件夹数量、筛选和排序，那么标签到底提供了哪些文件夹不能解决的能力？

这个问题很现实。

很多产品加标签，是因为用户说想要标签。但标签系统一旦做不好，就会变成另一套混乱的分类。文件夹、标签、收藏、搜索、筛选、项目、风格库之间如果边界不清，用户反而更难管理。

所以 Midjourney 团队现在更想收集具体工作流案例：用户到底在哪个场景下需要标签？文件夹为什么不够？是为了快速组合风格，还是为了跨项目复用，还是为了按主题、色调、摄影风格、角色关系做筛选？

对 Midjourney 来说，整理系统可能和生成模型一样重要。因为一旦用户开始长期创作，真正难的不是生成一张图，而是管理上千张图、数百个风格方向和反复试验的结果。

Omni-reference 指向更复杂的角色控制

原文还提到，未来的 Omni-reference / subject reference 系统，可能支持同时处理多个角色参考，并更好地分离不同主体。

这正好对应 AI 图像生成的长期痛点：角色一致性和多角色关系。

单个角色保持一致已经不容易，多角色更难。常见问题包括：

A 角色的特征跑到 B 角色身上。
多个人物之间身份混淆。
服装、发型、面部特征在不同图里不稳定。
参考图对整体风格影响过强，而不是只控制主体。

如果 Omni-reference 能更好地处理主体分离，那么 Midjourney 会更适合漫画、分镜、广告视觉、角色设定、游戏概念图和连续叙事。

这也是 V7 之后值得持续关注的方向。

Midjourney 正在重新理解 prompt

这次整理稿里还有一个很有意思的观点：语言是想象力的压缩层。

这句话很适合解释 Midjourney 的产品方向。

很多用户以为 AI 绘图的核心是写更长、更精确的 prompt。但实际创作里，图像参考、风格参考、moodboard、SREF、变体、重新生成和后期修图，往往比一段超长文本更有用。

Midjourney 团队成员 Duncan 的工作流也体现了这一点：他会把 Midjourney 当成 sketchbook，用 moodboard、SREF、少量文字、高 --r 再生成、强弱变体、Photoshop 修图和外部放大流程组合起来。

这说明 Midjourney 的成熟用户并不是只靠“神奇提示词”工作。

更真实的流程是：

用少量语言给方向。
用图片参考提供视觉语境。
用 SREF 收敛风格。
用大量变体探索空间。
用人工审美选择结果。
用外部工具做后期处理。

Prompt 仍然重要，但它不是全部。

对用户来说意味着什么

如果你只是偶尔生成图片，这次更新最直接的影响是会话模式更好用。未来你可能可以更自然地说出想要的比例、参考图、风格和参数，而不是记一堆命令。

如果你是重度用户，更值得关注的是三个方向。

第一，整理系统。

SREF、风格、文件夹、收藏和标签如何演进，会直接影响长期创作效率。

第二，网站改版。

新界面如果能把探索、整理、复用和导出串起来，Midjourney 会更像专业创作工具，而不是单一生成器。

第三，角色和主体参考。

Omni-reference 如果能稳定处理多角色和主体分离，会让 Midjourney 更适合连续项目，而不是只适合单张图。

小结

Midjourney 2026 年 5 月这次 Office Hours 的重点，不是某一个炫酷参数，而是产品正在继续向“创作系统”进化。

会话模式降低输入门槛，AI 辅助开发提高迭代速度，网站改版试图重组工作流，SREF 和标签讨论指向长期资产管理，Omni-reference 则关系到角色一致性和复杂主体控制。

对 AI 图像生成工具来说，模型能力当然重要。但当生成质量达到一定水平后，真正决定用户是否长期留下来的，往往是工作流、整理能力、可控性和迭代速度。

Midjourney 正在把这些部分补起来。

参考资料

Midjourney 最新ニュース（2026年5月14 日）｜アキスケ

OpenClaw 作者 Peter Steinberger 如何看 AI 软件开发？从 OpenClaw 到闭环编程

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger 的经历很适合用来观察 AI 软件开发正在发生什么变化。

他不是“突然被 AI 带火的新人”。在 OpenClaw 之前，他已经是 PSPDFKit 的创始人，长期做 PDF 渲染、文档处理和开发者工具。这类产品很难靠概念包装取胜，必须面对性能、兼容性、API 设计、企业客户和长期维护。

所以，当 Steinberger 后来用 AI 工具做出 OpenClaw，并围绕 AI Agent、个人自动化和 AI 编程发表观点时，重点不只是“一个人写了很多代码”。更值得看的，是他把多年软件工程经验和新一代 AI coding agent 结合后，对开发流程的重新理解。

AI 编程不是魔法按钮

很多人讨论 AI 编程时，会把它简化成两个极端。

一种说法是：AI 已经能写代码，程序员快没用了。

另一种说法是：AI 写的代码不可靠，真正工程还是得靠人手写。

Steinberger 的经验更接近第三种：AI 让软件开发的操作单位变了，但没有取消工程判断。

过去，开发者主要以“编辑代码”为中心工作。需求拆解、架构判断、写实现、跑测试、修 bug，都围绕人工修改代码展开。

AI coding agent 介入后，开发者越来越像在管理一个执行系统：

说明目标。
提供上下文。
约束边界。
让 agent 修改代码。
运行测试和检查。
根据结果继续迭代。

这不是简单把键盘交给模型，而是把人从“每一行都亲手敲”转到“定义方向、设计反馈、判断结果”。

为什么他不喜欢把这叫 vibe coding

围绕 Steinberger 的讨论里，一个高频词是 vibe coding。

这个词原本用来形容一种新开发方式：开发者用自然语言描述想法，让 AI 生成大量代码，再通过运行结果和反馈不断调整。

但 Steinberger 对这个词并不完全买账。公开报道中提到，他认为 vibe coding 容易变成一种贬义表达，暗示 AI 辅助开发只是“凭感觉乱生成”，忽视了背后的技能、判断和经验。

这个批评有道理。

真正有效的 AI 编程并不是随便输入一句话，然后相信模型输出。它需要：

能把模糊需求拆成可执行任务。
能识别模型是否误解了目标。
能设计测试和验收标准。
能判断代码结构是否会影响长期维护。
能知道什么时候应该停止生成、转向人工审查。

换句话说，AI 降低了写代码的摩擦，但没有降低理解系统的责任。

闭环才是关键

Steinberger 相关访谈和文章里，经常被总结出的一个核心思路是“闭环”。

只让 AI 生成代码，是开环。

让 AI 生成代码、运行代码、读取错误、修复问题、再运行测试，才更接近闭环。

这个差别非常重要。

开环生成很容易制造表面可用的软件。页面能打开，功能看起来有，代码也不少，但一旦进入真实场景，就会暴露状态管理、权限、异常处理、边界条件和部署问题。

闭环开发要求输出必须被反馈约束。最简单的闭环是：

写清楚目标。
让 AI 修改代码。
自动运行测试、类型检查、lint 或构建。
把错误反馈给 AI。
重复直到通过。
最后由人审查关键路径。

这也是 AI 软件开发真正能提高效率的地方。不是因为模型一次就写对，而是因为它可以快速参与“生成、验证、修复”的循环。

经验越多，越能用好 AI

AI 编程最容易产生的误解之一，是“经验不重要了”。

Steinberger 的案例反而说明，经验会变得更重要，只是作用方式变了。

一个有经验的工程师更容易判断：

哪些任务适合交给 agent。
哪些模块需要先写测试。
哪些改动风险太高，不该让 AI 大范围重构。
哪些生成代码只是看起来合理。
哪些问题应该通过架构调整解决，而不是继续补丁式修复。

AI 可以生成大量候选方案，但候选方案越多，越需要判断力。没有经验的人可能会被“能跑起来”迷惑，有经验的人更会追问：能不能维护？能不能扩展？会不会破坏安全边界？出了问题能不能定位？

这也是为什么 AI coding agent 并没有让软件工程变成纯聊天。它更像把一部分执行劳动外包出去，同时放大了规划、审查、验证和取舍的重要性。

OpenClaw 的意义不只是项目本身

OpenClaw 被关注，不只是因为它是一个开源 AI agent，也不只是因为它的增长速度快。

它更像一个信号：开发者开始希望 AI 不只回答问题，而是能接入真实工具，完成真实动作。

传统聊天机器人停留在对话框里。它可以解释代码、写草稿、给建议，但很多时候还需要人复制、粘贴、打开软件、执行命令。

Agent 的方向是把模型接到工具上：

文件系统。
浏览器。
终端。
邮件。
日历。
第三方服务。
项目仓库。

一旦模型能使用这些工具，软件开发的边界就会变化。AI 不再只是“代码补全”，而会参与项目阅读、任务拆解、文件修改、测试执行、PR 整理和工作流自动化。

这也是 Steinberger 加入 OpenAI 后被关注的原因。他代表的不是单个开发者故事，而是一种产品方向：个人 agent 会从演示玩具走向日常工作层。

这对普通开发者意味着什么

对普通开发者来说，Steinberger 的经验不一定能直接复制。

不是每个人都能同时管理多个 agent，不是每个项目都适合高强度 AI 生成，也不是每个团队都能接受“先生成再快速迭代”的节奏。

但有几件事值得学。

第一，先把任务写清楚。

AI 对含糊目标很敏感。你说“优化一下”，它可能改风格、改结构、加功能、删逻辑。你说“把登录失败时的错误提示从英文改成中文，不改变认证流程”，结果通常更可控。

第二，把验证命令固定下来。

如果一个项目没有测试、没有构建命令、没有 lint，AI 就很难形成闭环。哪怕只是最基础的 npm test、go test ./...、pytest、hugo，也比完全靠肉眼检查强。

第三，控制改动范围。

一次只让 AI 处理一个模块、一个 bug、一个页面，通常比让它“重构整个项目”更可靠。

第四，保留人工审查。

尤其是认证、支付、权限、数据删除、部署脚本、数据库迁移、安全配置这些地方，不要因为代码是 AI 生成的就降低审查标准。

第五，复盘 prompt 和失败模式。

如果 AI 经常误解某类任务，就把约束写进项目规则、agent instructions 或技能文件。AI 编程能力不是只来自模型，也来自你给它搭建的工作环境。

AI 软件开发会走向哪里

Steinberger 的故事说明，AI 软件开发正在从“辅助写代码”走向“组织软件生产流程”。

早期 AI 编程工具的价值主要是补全函数、解释报错、生成模板。现在的变化是，agent 可以跨文件工作，可以调用工具，可以运行检查，可以根据反馈继续修复。

这会带来几个趋势：

第一，个人开发者的产能上限会提高。

一个人可以同时推进更多原型、脚本、内部工具和小型产品。但产能提高不等于质量自动提高。越快生成，越需要验证。

第二，项目结构会更重要。

代码越清晰，测试越明确，文档越完整，AI 越容易正确修改。混乱项目对人难，对 AI 也难。

第三，软件工程师会更像工作流设计者。

未来重要的不只是会不会写某门语言，而是能否把需求、上下文、工具、测试、部署和权限组织成一个可控循环。

第四，安全边界会更敏感。

Agent 能做事，就可能做错事。它能读文件、执行命令、访问服务，也意味着权限、审计和回滚会成为 AI 开发环境的基础设施。

小结

Peter Steinberger 的 AI 软件开发观，最有价值的地方不是“AI 生成了多少代码”，而是他展示了一种新的开发姿势。

人不再只是在编辑器里逐行输入，而是在设计目标、管理 agent、构造反馈回路、审查结果和调整系统。代码仍然重要，但代码不再是唯一的劳动中心。

如果说传统软件开发强调“把代码写对”，AI 软件开发会更强调“让系统持续产出可验证的正确结果”。

这不是降低工程门槛那么简单。它是在改变工程能力的形态：从手工实现，转向任务分解、上下文管理、工具编排、自动验证和最终判断。

参考资料

Google Gemini Spark 爆料解读：一个 24 小时在线的 Gemini Agent 可能要来了

Sun, 17 May 2026 11:58:08 +0800

Google 还没有正式发布 Gemini Spark。

目前关于它的信息，主要来自 Gemini Web 内部测试界面、社区截图、TestingCatalog 报道，以及 36Kr / 新智元对相关爆料的整理。比较一致的说法是：Gemini Spark BETA 可能是 Google 正在准备的全天候 AI Agent，定位不再只是聊天助手，而是能在后台处理邮件、在线任务和多步骤工作流的“日常 AI 代理”。

所以这篇文章先把边界说清楚：这是爆料解读，不是 Google 官方发布稿。所有功能、命名和上线时间，都要等 Google 正式公告确认。

先说结论

从目前曝光的信息看，Gemini Spark 有三个重点：

它可能是 Gemini 体系里的 24 小时在线 Agent，而不是普通聊天模型。
它会调用更广泛的个人上下文，包括 Google 应用、聊天记录、任务、登录网站和位置信息等。
它的风险和吸引力一样大，因为它可能涉及信息分享、远程浏览器数据、购买动作和第三方服务调用。

如果 Google 真把 Spark 推出来，Gemini 的定位会发生变化：从“回答问题的 AI”变成“替你持续处理事务的 AI”。

Gemini Spark 是什么

TestingCatalog 在 2026 年 5 月 14 日报道，Google 正在 Gemini Web 中测试 Gemini Spark BETA。曝光的欢迎文案把它描述成一个 everyday AI agent，可以 24/7 帮用户处理 inbox、online tasks 和更多多步骤工作。

36Kr / 新智元的文章也提到，Spark 被扒出后，外界看到的是一个“全时 Agent”方向：它可以全天候待命，处理收件箱、执行在线任务，甚至可能涉及购买和信息分享。

这意味着 Spark 不是一个单纯的新模型名。它更像是 Gemini 产品层的一次升级：让 Gemini 从对话窗口里走出来，进入用户的邮件、网页、日程、任务和跨应用工作流。

它可能怎么工作

根据 TestingCatalog 披露的隐藏 onboarding 文案，Gemini Spark 会从多种来源获取上下文，包括：

Connected Apps。
skills。
chats。
tasks。
用户登录过的网站。
Personal intelligence。
location。

这些信息会帮助 Spark 理解用户想完成什么，并在执行任务时调用必要的上下文。文案还提到，为了完成某些动作，Gemini 可能会把必要信息分享给第三方，例如姓名、联系方式、文件、偏好，以及用户可能认为敏感的信息。

如果这些描述最终属实，Spark 的工作方式会更接近“带上下文的代理系统”，而不是一次性问答。它不是只看当前一句 prompt，而是可能综合长期偏好、连接应用、浏览器状态和任务历史。

为什么它重要

Gemini Spark 的关键，不在于多一个聊天入口，而在于 Google 有天然的生态入口。

OpenAI 和 Anthropic 可以做很强的 Agent，但它们很难天然拥有 Gmail、Calendar、Drive、Chrome、Android、Workspace 这条完整链路。Google 如果把 Spark 接进这些产品，用户不需要额外搭建太多工作流，就能让 Agent 进入日常事务。

这会带来三个变化。

第一，Gemini 会从被动问答变成主动执行。用户不再只是问“帮我总结这封邮件”，而是可能让它持续整理 inbox、追踪任务和执行后续动作。

第二，Agent 会更依赖个人上下文。它越懂你的邮件、日程、文件、浏览器状态和偏好，越可能给出有用结果。

第三，权限边界会变得更敏感。能做更多事，也意味着需要更清楚地知道它什么时候能做、能做到哪一步、是否需要确认。

风险点在哪里

TestingCatalog 披露的文案里，有几处很值得关注。

第一，Spark 是 experimental。也就是说，即便它上线，也不应被当成完全成熟、无需监督的系统。

第二，虽然系统设计上会在敏感操作前征求许可，但文案也提示，它可能会在未经询问的情况下分享信息或完成购买。

第三，为了保持会话连续性，Gemini 会保存 remote browser data，比如登录细节和 remote code execution data。用户可以在 Settings 中清除这些数据，也可以关闭 Connected Apps 和 Personal intelligence 相关能力。

这几个点合在一起，说明 Spark 的产品方向很激进：它要做真正能执行任务的 Agent，而不是只生成建议。但越接近真实执行，越需要严格的权限、审计、确认和回滚机制。

和 Remy、AI Ultra 的关系

TestingCatalog 提到，Spark 可能是此前内部代号 Remy 的 agentic Gemini upgrade 的重命名版本，也与面向 Google AI Ultra 订阅用户的 Gemini Agent 方向有关。

如果这个线索成立，Spark 可能不是凭空出现的新项目，而是 Google 把此前较高阶、较封闭的 Agent 能力重新包装，并准备推向更大范围用户。

36Kr / 新智元也把它描述成从 “Remy” 到 “Spark” 的升级：Gemini Agent 不再只是一个功能，而是要走向 24/7 的数字生活管家。

不过这仍然是基于爆料信息的判断。Google 是否会使用 Spark 这个正式名称、是否只面向 AI Ultra、是否推出更轻量订阅层，还要等官方确认。

MCP、skills 和工具生态

同一批社区截图里，还出现了 MCP Tool Testing 这类模型选择器入口。36Kr 文章认为，这可能暗示新 Gemini 会原生支持 MCP 第三方工具接入，Thinking 模式也会重构。

这条线索和 Spark 放在一起看，很有意思。

如果 Spark 只是“会聊天的助手”，skills 和 MCP 的意义有限。但如果 Spark 是一个长期运行的 Agent，它就需要可靠地调用工具、访问网页、执行任务、读写上下文，并把结果交付给用户。

也就是说，Spark 可能不是单点功能，而是 Google Agent 工具生态的一部分：模型负责理解和规划，skills / MCP / connected apps 负责执行和扩展。

对普通用户意味着什么

如果 Gemini Spark 真的发布，普通用户最直接的变化可能是：

邮件不只是被总结，而是可以被分类、跟进和转成任务。
网页任务不只是给建议，而是可能在远程浏览器中持续执行。
日程、位置、偏好和历史对话会变成 Agent 的长期上下文。
购买、预订、表单填写等动作可能进入 AI 执行范围。

这听起来很方便，但用户需要建立新的习惯：不再只看 AI 说了什么，还要看 AI 准备做什么、已经做了什么、能不能撤回、有没有记录。

未来 AI Agent 的体验好不好，可能不只取决于模型聪不聪明，还取决于权限提示是否清楚、任务日志是否可查、错误操作能不能恢复。

对开发者和团队意味着什么

对开发者来说，Spark 的意义在于 Google 可能正在把 Agent 从“演示产品”推向真实工作流平台。

如果 Spark 能稳定连接 Google 应用、第三方工具和浏览器状态，那么开发者会关心：

API 或扩展机制是否开放。
MCP 或 skills 是否可由第三方接入。
企业管理员能否控制权限、数据留存和审计。
Agent 执行失败时是否有可追踪日志。
是否支持沙盒、审批流和敏感操作确认。

对团队来说，Spark 可能会先从 Gmail、Calendar、Docs、Drive、Chrome 这类高频场景切入。它未必一开始就适合完全自动化高风险业务，但很适合作为 inbox triage、会议跟进、资料整理、市场研究和轻量运营任务的助手。

现在应该怎么看

这条消息适合用“高可信方向，低确定细节”来理解。

高可信方向是：Google 确实在推进更主动、更长期运行、更深度接入生态的 Gemini Agent。TestingCatalog 报道的 Gemini Web 测试文案、社区截图和 36Kr 整理的多方爆料，都指向同一个方向。

低确定细节是：正式名称、上线时间、权限规则、订阅层级、可用地区、是否开放 API、是否真的叫 Gemini Spark，都还不能下结论。

所以现在最稳妥的判断是：

不要把 Spark 当成已经发布的正式产品。
可以把它视为 Google 下一阶段 AI Agent 路线的强信号。
真正值得等的是官方如何解释权限、隐私、第三方数据分享和远程浏览器数据保存。

总结

Gemini Spark 如果最终发布，可能会是 Gemini 从聊天助手走向全天候 Agent 的关键一步。它不只是换一个模型，而是把 Gemini 放进 Google 生态的邮件、网页、任务、位置、个人智能和第三方服务里。

它的潜力很大：更主动、更贴近真实工作流，也更容易借助 Google 的生态分发给大量用户。它的风险也同样大：一旦 AI 能分享信息、保存浏览器状态、执行购买和调用第三方服务，权限边界就必须非常清楚。

所以 Gemini Spark 最值得关注的不是“它有多聪明”，而是 Google 准备怎样让一个 24 小时在线的 AI Agent 变得可控、可审计、可信任。

参考链接：

Gemini 3.5 Pro 曝光：代号 Cappuccino，谷歌想在编程和 Agent 上追回节奏

Sun, 17 May 2026 11:47:27 +0800

Google 还没有正式发布 Gemini 3.5 Pro。

目前能看到的信息，主要来自开发者社区截图、匿名跑分、爆料人消息和媒体转述。36Kr / 新智元在 2026 年 5 月 15 日整理称，新一代 Gemini 检查点内部代号可能是 Cappuccino，相关模型已经在社区和评测平台中提前曝光。

这类信息还不能等同于官方发布，但它透露出一个清晰方向：Google 正在试图同时补上两块短板，一块是编程和推理能力，另一块是全天候 AI Agent。

先说结论

这次爆料可以拆成三层来看：

Gemini 3.5 Pro 尚未正式发布，Cappuccino 更像是内部检查点或候选版本代号。
曝光信息显示，新 Gemini 在代码生成、SVG / 交互式 Web 生成、多模态输出上有明显提升。
Google 同步测试的 Gemini Spark，可能比模型本身更关键，因为它指向 24 小时运行的个人 AI Agent。

换句话说，这不是一条简单的“模型跑分新闻”。它更像是 Google 在 I/O 前释放出的产品路线信号：模型要追赶 GPT-5.5，Agent 要抢占用户工作流入口。

Cappuccino 是什么

36Kr 文章提到，网友 Lentils 放出的消息显示，代号 Cappuccino 的 Gemini 3.5 Pro 检查点已经开始产出。此前社区还在讨论 Gemini 3.2，但最新曝光直接跳到了 3.5。

如果这个命名最终属实，说明 Google 可能希望把下一代 Gemini 包装成一次更大的版本跃迁，而不是普通小版本更新。

需要注意的是，Cappuccino 现在仍应被视为爆料中的内部代号。它不等于 Google 已经公开上线的正式模型，也不代表最终发布名一定就是 Gemini 3.5 Pro。

编程能力为什么是焦点

这次爆料里最受关注的点，是新 Gemini 的编程能力。

36Kr 引述的社区截图和跑分信息显示，新模型在以下任务上表现更强：

生成 SVG 与视觉组件。
生成交互式 Web 应用。
处理动画、3D、可调参数面板等复杂前端输出。
逻辑推理和代码生成能力有所提升。

文章还提到，Abacus.AI CEO Bindu Reddy 转述的说法是，3.2 Flash 在编码和推理上接近 GPT-5.5 的水平，同时成本更低。另有媒体信源则认为，新款 Gemini 的整体性能大致追平 GPT-5.5，但未必能带来质变。

这也是为什么要谨慎看待“追平 GPT-5.5”这句话。它更像是不同爆料源和匿名评测中的相对判断，而不是 Google 官方给出的基准测试结论。

为什么 Google 急着补编程

AI 编程已经从开发者工具变成了大模型竞争的核心战场。

OpenAI 有 Codex，Anthropic 有 Claude Code。它们不只服务工程师，也在把产品经理、设计师、运营人员带进“自然语言生成可运行产品”的工作流里。

相比之下，Google 虽然有 Gemini 和 Antigravity，但在开发者心智里一直没有形成同等强度的默认入口。36Kr 文章也提到，Antigravity 在外部市场还没有真正突围，定价、额度提醒和体验稳定性都曾引发社区讨论。

所以新 Gemini 如果要证明自己，编程会是最直接的战场。它不一定只比拼“会不会写代码”，还要比拼能不能稳定产出完整界面、理解复杂需求、调用工具、修复错误并融入真实开发流程。

Spark 可能比 3.5 Pro 更重要

同一波爆料里，Gemini Spark BETA 也被扒出。

根据 TestingCatalog 等信息源的说法，Spark 的定位接近“全天候 AI Agent”：它可以处理收件箱、执行在线任务、管理多步骤工作流，并连接 Google 应用、技能模块、聊天记录、定时任务、登录网站、位置信息等上下文。

这意味着 Spark 不是一个普通聊天入口，而是一个可能长期在线、持续读取上下文并替用户执行任务的系统。

它的吸引力很明显：如果 Google 能把 Gmail、Calendar、Chrome、Android、Workspace 和 Gemini 串起来，Spark 会天然拥有 OpenAI 和 Anthropic 很难复制的分发优势。

但风险也同样明显。36Kr 文章提到，Spark 相关说明中出现了“可能在未经询问的情况下分享信息或完成购买”的表述。哪怕系统设计上会在敏感操作前征求许可，这类 Agent 仍然会带来隐私、授权边界和误操作风险。

这对普通用户意味着什么

如果你只是普通 Gemini 用户，这次爆料真正值得关注的不是模型名，而是三个变化：

第一，Google 可能会继续强化“生成完整结果”的能力。以前用户经常吐槽 Gemini 在视觉生成、SVG、前端页面上容易偷懒，如果新模型能一次给出多个完整方案，体验会明显改善。

第二，编程能力会继续下放到更轻量的模型。爆料里反复提到 Flash 版本在编码、推理和交互式生成上的提升，这意味着未来不一定只有 Pro 模型才能处理复杂任务。

第三，Agent 会变得更主动。Spark 如果发布，Gemini 可能不再只是回答问题，而是开始长期接管邮件、网页、购买、日程和跨应用任务。

这对效率是好消息，对权限管理则是新挑战。

这对开发者意味着什么

开发者更应该关注两个问题。

第一个问题是工具生态。36Kr 文章提到，社区从模型选择器里看到了 MCP Tool Testing 这类未公开入口。如果 Gemini 原生支持 MCP 或第三方工具测试，那么它会更容易接入开发者自己的工具链。

第二个问题是成本和稳定性。即便新 Gemini 在某些基准上追平 GPT-5.5，开发者最终还是会看三件事：实际代码质量、上下文稳定性、价格和额度是否可预期。

过去一年，AI 编程工具竞争已经证明，模型能力只是门票。真正让开发者留下来的，是能不能在日常项目里持续可靠地改代码、跑测试、读上下文、处理边界条件。

现在应该如何看待这条消息

这条消息适合用“强信号、弱确认”来理解。

强信号在于：多个社区线索都指向 Google 正在准备更强的新 Gemini，以及更主动的 Gemini Spark Agent。

弱确认在于：Gemini 3.5 Pro 还没有官方发布，Cappuccino 仍是爆料代号，所谓“追平 GPT-5.5”的说法也需要等 Google 官方基准、第三方评测和真实用户测试来验证。

所以现在最稳妥的判断是：

不要把它当成已发布产品。
可以把它当成 Google 下一阶段 Gemini 路线的提前预告。
重点关注 I/O 或后续官方活动中是否会确认模型命名、API 可用性、价格、上下文窗口、工具调用和 Agent 权限边界。

总结

Gemini 3.5 Pro / Cappuccino 的曝光说明，Google 可能正在为下一代 Gemini 做一次更强势的版本推进。它要补的不是单一能力，而是整个 AI 工作流：模型要更会写代码、生成界面和处理复杂推理，Spark 则要把 Gemini 推向全天候 Agent。

但在官方发布前，所有跑分和截图都只能作为线索。真正决定 Gemini 3.5 Pro 能否翻身的，不是代号是否好听，而是它能否在真实开发、真实办公和真实多步骤任务里稳定胜出。

参考链接：

easy-vibe：给 Vibe Coding 初学者的一张学习地图

Sat, 16 May 2026 22:44:43 +0800

easy-vibe 是 Datawhale 开源的 Vibe Coding 学习项目。它面向的不是已经熟练使用 AI 编程工具的开发者，而是刚开始接触 Vibe Coding 的学生、产品经理、设计师、运营、独立开发者和普通技术爱好者。

这个项目的价值不在于又列出一批 AI 工具，而是把“怎么开始用 AI 做项目”拆成了更容易理解的学习路径。对很多新手来说，真正困难的不是不知道有 Claude Code、Cursor、MCP 或 Agent，而是不知道应该先学什么、怎么练、什么时候进入进阶工具。

Vibe Coding 新手最缺的是路径

Vibe Coding 这几年很火，但它对新手并不友好。

表面上看，只要会描述需求，就可以让 AI 写代码。实际上，只要任务稍微复杂一点，问题就会出现：需求说不清，模型改错文件，项目结构看不懂，报错不会处理，依赖装不上，提示词越写越乱，最后只能回到“复制代码到聊天框”的状态。

所以 Vibe Coding 入门不能只教“怎么写提示词”。它至少要解决几件事：

如何把想法拆成可执行任务；
如何让 AI 理解项目结构；
如何看懂模型生成的代码；
如何处理报错和迭代；
如何使用终端和本地开发环境；
如何从网页聊天过渡到真正的 AI 编程工具。

easy-vibe 的意义就在这里：它试图把这些内容整理成一条学习路线，而不是让新手自己在工具、教程和术语里迷路。

它不是单点教程，而是路线图

从项目介绍看，easy-vibe 覆盖了基础教程、交互式练习、可视化内容、RAG、终端工具、AI 编程工具，以及更进阶的 Claude Code、MCP、Skills、Agent Teams 等主题。

这类组织方式比较适合初学者。因为 AI 编程不是一个单独技能，而是一组能力的组合：

会描述需求；
会拆任务；
会读项目；
会让模型改代码；
会运行和验证；
会根据错误继续迭代；
会把常用流程沉淀成工具或技能。

如果只学某一个工具，很容易被工具界面限制住。换一个模型、换一个编辑器、换一个 CLI，就又不知道怎么做。路线图的好处是先建立工作方式，再把工具放到合适的位置。

对非程序员尤其有用

Vibe Coding 最大的吸引力，是让非专业程序员也能做出原型。

产品经理可以把产品想法变成可交互 demo，设计师可以验证交互逻辑，运营可以写内部工具，学生可以快速做课程项目，创业者可以在早期验证需求。这些人不一定要成为传统意义上的全职工程师，但需要掌握一套“让 AI 帮我把想法落地”的方法。

这也是 easy-vibe 适合中文社区的原因。很多中文用户已经知道 AI 能写代码，但还缺少系统入门材料：从开发环境、提示词、项目结构、调试方法到 Agent 工具使用，最好能用中文解释清楚，并配合练习逐步推进。

对这类用户来说，最重要的不是一上来学复杂框架，而是先跑通完整闭环：提出需求、生成项目、运行起来、发现问题、继续修改、最终得到一个可用版本。

进阶部分开始靠近真实 AI 开发工作流

easy-vibe 里提到的 Claude Code、MCP、Skills、Agent Teams，已经不只是入门概念。

Claude Code 代表的是终端编程 Agent：模型可以进入本地项目，读取文件、修改代码、运行命令。MCP 解决的是工具和数据源接入，让模型不只停留在聊天框里。Skills 则把可复用流程沉淀下来，例如固定的项目生成、文档整理、测试检查或内容生产流程。Agent Teams 进一步把任务拆给多个智能体协作。

这些内容对新手来说可能有点远，但它们值得提前了解。因为 Vibe Coding 的发展方向已经很清楚：从“让 AI 写一段代码”，走向“让 AI 参与一个完整项目流程”。

如果学习路线只停留在提示词层面，很快就会跟不上工具演进。反过来，如果一开始就把所有高级概念塞给新手，又会让人无从下手。easy-vibe 的合理价值，是把这些内容放在一条逐步升级的路径里。

学习时要避免两个误区

第一个误区，是以为 Vibe Coding 等于不会代码也能完全不管代码。

AI 可以生成很多内容，但用户仍然需要判断结果是否正确。至少要能看懂项目结构、知道怎么运行、知道错误大概发生在哪里。即使不写复杂代码，也要具备基本的工程常识。

第二个误区，是以为工具越高级越好。

新手不一定一开始就需要 Claude Code、MCP 或多 Agent。更好的顺序是先用简单项目建立反馈循环，再逐步引入终端、版本管理、测试、工具调用和自动化流程。工具要跟任务复杂度匹配，否则很容易变成“看起来很强，但不知道用来做什么”。

适合怎么用

如果你刚接触 Vibe Coding，可以把 easy-vibe 当作学习清单来用。

先从基础概念和简单练习开始，不急着追所有工具。做一个小项目，例如个人主页、数据看板、表单工具、自动化脚本或知识库 demo。过程中重点观察 AI 在哪些地方帮得上忙，哪些地方需要你自己确认。

等你能稳定完成小项目，再开始学习更复杂的内容：

用终端工具处理本地项目；
用 Git 管理每次修改；
用 RAG 接入自己的资料；
用 MCP 连接外部工具；
用 Skills 固化重复流程；
用 Agent Teams 拆分复杂任务。

这样学出来的 Vibe Coding 才不只是会问 AI，而是能把 AI 放进自己的工作流程里。

总结

easy-vibe 适合被看作 Vibe Coding 的中文入门地图。它把零散的 AI 编程概念、工具和练习组织成一条路径，让新手更容易从“听说 AI 能写代码”走到“我能用 AI 做出一个项目”。

Vibe Coding 真正有价值的地方，不是让人跳过所有学习，而是降低从想法到原型的门槛。你仍然需要理解需求、组织任务、验证结果和控制风险，但很多重复、枯燥、容易卡住的步骤，可以交给 AI 协助完成。

如果你想系统入门 AI 编程，又不想一开始就陷入工具名词和复杂工程配置，easy-vibe 是一个值得收藏的起点。

Anthropic financial-services：把金融 Agent 场景做成可复用模板

Sat, 16 May 2026 22:43:08 +0800

anthropics/financial-services 是 Anthropic 面向金融服务行业发布的参考项目。它不是一个单一应用，而是一组可以拆开学习和复用的示例：Agents、Plugins、Skills、MCP 连接器，以及围绕金融工作流设计的提示词和集成方式。

这个项目值得关注，不是因为它提供了某个“万能金融助手”，而是因为它把金融行业里常见的 AI 落地问题拆成了更具体的组件：不同岗位需要什么 Agent、哪些数据源需要接入、哪些任务可以自动化、哪些环节仍然需要人工判断。

它更像金融 Agent 的样板间

很多企业谈 AI Agent 时，容易停留在抽象层面：能读文件、能查数据、能写报告、能调用工具。但真正进入金融场景后，问题会变得具体得多。

投行分析师需要整理公司资料、生成交易简报、比对可比公司；股票研究需要读财报、看新闻、做估值和风险分析；私募和资管团队要筛项目、写 memo、跟踪组合公司；财富管理要把客户画像、市场信息和投资建议放在一个合规框架里。

这些场景不能只靠一个通用聊天框完成。它们需要角色、流程、数据源、输出格式和权限边界。Anthropic 这个仓库的价值就在这里：它把金融服务行业里的多个典型岗位和任务拆成可以参考的 Agent 模板。

为什么要同时提供 Agents、Plugins、Skills 和 MCP

从项目结构看，Anthropic 没有只给一套提示词，而是同时提供了多种组件。这背后其实对应了企业落地 Agent 的几层需求。

Agents 更像面向角色或任务的工作单元。它定义“这个智能体要做什么、怎样做、何时调用工具、如何输出结果”。

Plugins 更像外部能力扩展。金融工作很少只发生在模型内部，往往要连接数据库、文档系统、市场数据、CRM、研究库和内部流程系统。

Skills 更像可复用的专业能力包。比如固定格式的分析框架、报告结构、检查清单、数据处理方法，都可以沉淀成技能，而不是每次重新写提示词。

MCP 连接器则解决工具接入和上下文标准化问题。对企业来说，工具越多，越需要一个相对统一的连接方式，否则每个系统都要单独适配，维护成本会很高。

这几个部分组合起来，才更接近真实企业里的 AI 工作流。

金融行业为什么适合做 Agent 示例

金融服务是很适合展示 Agent 的行业，因为它同时具备三个特点。

第一，信息密度高。金融工作大量依赖财报、公告、会议纪要、研究报告、交易数据、客户资料和监管文件。模型如果只靠通用知识，很快就会失效，必须接入真实数据源。

第二，输出格式稳定。投资备忘录、公司简介、KYC 文件、研究摘要、客户简报、基金运营报告，都有相对固定的结构。这让 Agent 更容易形成可验证的工作流。

第三，风险边界清楚。金融行业对合规、审计、权限和可追溯性要求很高。AI 不能随意给投资建议，也不能绕过审批流程。这反而逼着 Agent 设计得更工程化：要保留引用、区分事实和推断、记录工具调用、限制可执行操作。

所以这个项目不只是给金融公司看的。任何想做企业级 Agent 的团队，都可以从里面观察 Anthropic 如何拆解行业场景。

它覆盖了哪些典型流程

从项目说明看，这个仓库覆盖了多个金融服务方向，包括：

投资银行；
股票研究；
私募股权；
财富管理；
基金运营；
KYC 和合规相关流程。

这些流程的共同点是：都需要大量阅读、整理、比对和生成结构化材料。AI 在这里最适合做的，不是直接替人拍板，而是减少信息处理和文档生产的时间。

例如，投行场景里，Agent 可以帮忙整理目标公司资料、抽取关键财务指标、生成初版交易摘要。研究场景里，它可以先读财报和新闻，列出关键变化和待确认问题。KYC 场景里，它可以辅助检查资料是否完整、是否存在异常线索。

最终判断仍然应该由专业人员负责。Agent 的角色更像助理、分析员和流程加速器。

对企业落地的启发

这个仓库最有参考价值的地方，是它把“模型能力”转成了“业务组件”。

企业内部做 AI 项目时，经常会遇到一个问题：模型演示很好看，但真正接入业务后很难复用。一个团队写了一套提示词，另一个团队又重新写一套；一个系统接了数据库，另一个系统又重新做接口；安全和审计要求也散落在各处。

更稳妥的方式是把能力拆成几类资产：

面向岗位的 Agent；
面向流程的 Skills；
面向系统接入的 MCP 连接器；
面向权限和审计的执行规则；
面向业务输出的模板和检查清单。

这样做的好处是，企业不会每次都从“写一个聊天机器人”开始，而是逐步积累可维护的 AI 工作流资产。

不能忽视合规和责任边界

金融 Agent 最容易被误解的一点，是把“能生成分析”误认为“可以替代决策”。

在金融服务里，AI 输出通常只能作为辅助材料。它可以整理事实、生成草稿、提示风险、补全文档，但不能绕过投研、风控、法务、合规和客户适当性要求。尤其是涉及投资建议、交易决策、客户资产配置和身份审查时，人工审批和责任链必须保留。

这也是为什么企业级 Agent 不能只看模型回答质量。它还要看：

数据来源是否可靠；
引用和证据是否可追溯；
工具调用是否有记录；
敏感数据是否被限制；
输出是否经过人工确认；
错误结果能否被发现和回滚。

这些问题不解决，Agent 越自动化，风险半径就越大。

总结

anthropics/financial-services 更像一套金融 Agent 参考实现，而不是一个开箱即用的金融产品。它展示了 Anthropic 对企业 AI 落地的一种思路：不要只做通用聊天助手，而是围绕具体岗位、具体流程、具体数据源和具体权限边界来组织 Agent。

对金融机构来说，它可以作为内部 AI 工作流设计的参考。对开发者来说，它提供了一个观察企业级 Agent 架构的样本：Agents 负责角色和任务，Skills 沉淀专业流程，Plugins 和 MCP 负责连接外部系统，最终让模型进入真实业务流程。

如果说早期 AI 工具解决的是“怎么让模型回答问题”，这类项目更关心的是“怎么让模型在受控边界内参与工作”。这才是企业级 Agent 真正难的地方。

DeepSeek-TUI：把 DeepSeek V4 变成终端里的编程智能体

Sat, 16 May 2026 22:41:41 +0800

DeepSeek-TUI 是一个把 DeepSeek V4 接入终端开发流程的开源项目。它不是普通聊天壳，而是更接近 Claude Code、Codex CLI 这类“命令行编程智能体”：能看文件、改代码、执行命令、调用工具，并在终端里用 TUI 方式持续推进任务。

如果你已经习惯在编辑器和终端之间切换，这类工具的价值很直接：不用把代码来回复制到网页对话框里，也不用手动描述完整项目结构。你把任务交给它，它可以在当前工作区里读取上下文、规划步骤、执行修改，再把结果交还给你审查。

它解决的是 DeepSeek 的使用入口问题

DeepSeek 模型本身提供了很强的推理和代码能力，但模型能力要落到真实开发流程里，还需要一层工程化外壳。

网页聊天适合问问题，不适合长时间改项目。API 适合接入系统，但普通开发者还要自己写工具调用、上下文管理、文件读写和权限控制。DeepSeek-TUI 想补上的正是这一层：把 DeepSeek V4 包成一个可以在终端里工作的 Agent。

从项目介绍看，它的重点能力包括：

终端 TUI 界面；
面向 DeepSeek V4 的对话与任务执行；
工具调用和文件操作；
1M 上下文支持；
Auto 模式；
子智能体；
沙箱执行；
持久化任务队列。

这些功能组合起来，目标不是“让模型回答得更像人”，而是让模型更容易进入开发现场。

TUI 比纯命令行更适合长任务

很多 AI CLI 工具一开始都是纯文本交互：输入提示词，等待输出，再复制命令或补充上下文。这种方式简单，但任务一长就容易混乱。

TUI 的好处是能把会话、文件、执行结果、任务状态放在一个更稳定的界面里。对编程 Agent 来说，这很重要。因为一次代码任务往往不是一问一答，而是包含：

理解项目结构；
查找相关文件；
修改代码；
运行测试或命令；
根据报错继续修复；
总结变更。

如果界面只是一串日志，用户很难快速判断 Agent 走到了哪一步。TUI 至少给了一个更适合观察和接管的入口。

Auto 模式适合明确边界的任务

DeepSeek-TUI 提到的 Auto 模式，适合用在边界比较清楚的工作里。例如修一个小 bug、补一个脚本、改一段配置、整理一组文档、实现一个局部功能。

这类任务的共同点是：目标清楚，检查方式明确，影响范围可控。Agent 可以自己查文件、改文件、跑命令，然后把结果交给用户确认。

但 Auto 模式不适合无限放权。尤其是在真实项目里，文件删除、批量重构、数据库迁移、部署命令都应该有明确确认。编程 Agent 的效率来自自动化，但风险也来自自动化。越是能执行命令的工具，越需要沙箱、权限边界和人工审查。

子智能体的意义在于拆任务

子智能体不是新概念，但放在代码场景里很有用。

一个稍复杂的任务，通常会同时需要几类工作：有人负责读代码，有人负责改实现，有人负责检查测试，有人负责整理文档。传统多 Agent 系统经常显得花哨，是因为它们没有真实工具和真实工作区，只是在对话里互相讨论。

如果子智能体能结合文件系统、命令执行和任务队列，它就更像一种任务拆分机制。比如一个子智能体专门分析依赖关系，另一个负责修改某个模块，主智能体再整合结果。这样可以减少单个上下文里堆太多无关信息的问题。

当然，子智能体也会带来额外成本：更多 token、更复杂的状态、更难追踪的责任边界。所以它适合中等复杂度以上的任务，不一定适合每一次小修改。

1M 上下文不是万能，但很适合读项目

1M 上下文听起来很夸张，但在编程场景里并不只是营销数字。

真实代码库的上下文很碎：README、配置文件、类型定义、测试、调用链、历史约定、错误日志，都可能影响一次修改。更长上下文能减少“只看局部就动手”的问题，也能让模型保留更多项目约束。

不过，上下文长不等于判断一定更准。代码任务仍然需要检索、筛选和验证。把整个项目塞进上下文并不一定比精准读取相关文件更好。好的编程 Agent 应该把长上下文当作缓冲区，而不是把它当成替代工程判断的捷径。

更适合哪些用户

DeepSeek-TUI 更适合几类人：

想在终端里使用 DeepSeek 做代码任务的开发者；
不想自己搭工具调用和文件操作框架的人；
已经熟悉 Claude Code、Codex CLI，但想尝试 DeepSeek 模型入口的人；
需要本地项目上下文，而不是只在网页里问代码片段的人；
想把 AI 编程流程放进命令行环境的人。

如果你只是偶尔问一个函数怎么写，网页聊天已经够用。如果你希望模型直接参与项目修改，终端 Agent 才更有意义。

需要关注的风险

这类工具最需要关注三件事。

第一是权限。只要工具能读写文件、执行命令，就要确认它默认能访问哪里、能不能删除文件、能不能联网、危险命令是否需要确认。

第二是可回滚。使用前最好保持 Git 工作区干净，让每次 Agent 修改都能被 git diff 清楚看到。不要在一堆未提交改动里让 Agent 自动改项目。

第三是验证。Agent 写完代码不代表任务完成。测试、构建、lint、人工 review 仍然要保留。AI 编程工具可以提高推进速度，但不能替代最后的工程确认。

总结

DeepSeek-TUI 的意义不在于又多了一个聊天客户端，而在于它把 DeepSeek V4 放进了更接近真实开发工作的终端环境里。

对开发者来说，模型能力只是第一步。真正影响体验的是：它能不能读项目、能不能安全改文件、能不能执行验证命令、能不能在长任务里保持状态、能不能让用户随时接管。

如果你想把 DeepSeek 用在日常代码修改、项目阅读和自动化开发任务里，DeepSeek-TUI 值得关注。它代表的方向也很清楚：AI 编程工具正在从“回答代码问题”转向“参与项目执行”。

AI Agent 到底怎么进化的？2022-2026 五代演进完整梳理

Sat, 16 May 2026 19:19:52 +0800

AI Agent 的发展不是一夜之间发生的。

2022 年底，ChatGPT 还只是一个会聊天的窗口。到 2026 年，Agent 已经开始具备工具调用、文件操作、电脑控制、长期记忆、远程协作和常驻执行能力。四年时间里，它从“回答问题的模型”逐步变成“能推进任务的数字工作者”。

如果按时间线看，AI Agent 大致经历了五代演进。每一代都解决了上一代的核心缺陷，也制造了新的泡沫和新的安全问题。

总览：五代 Agent 时间线

阶段	时间	关键词	能力变化	核心问题
第零代	2022 年末 - 2023 年初	对话框	会生成文本，但不能行动	模型和现实世界断裂
第一代	2023 年中 - 2023 年末	工具调用	能输出结构化调用，接入 API 和 RAG	开环循环、任务迷路
第二代	2023 年末 - 2024 年	工程化工作流	有规划、状态、反思和多 Agent 协作	工作流易复制，低代码泡沫
第三代	2024 年 - 2025 年	Computer Use	能看屏幕、点鼠标、操作 GUI	权限、安全和误操作风险
第四代	2025 年 - 2026 年	MCP / Skills / 常驻	有工具网络、长期上下文和专业技能	常驻执行扩大风险半径
第五代前瞻	2026 年之后	闭环与世界模型	可能拥有更强记忆、验证和物理行动能力	治理难度继续上升

下面按时间线展开。

2022 年末：第零代，ChatGPT 对话框时代

第零代的起点，是 2022 年 11 月 30 日 ChatGPT 发布。

这一代 AI 还不能算真正的 Agent。它有很强的语言生成能力，但主要被困在对话框里。它可以写一段 Python 代码，却不能在你的电脑上运行；可以规划旅行，却不能打开网站订票；可以告诉你文件应该怎么改，却不能进入文件系统执行修改。

这一代的能力边界很清楚：

能理解自然语言；
能生成文章、问答、代码和方案；
不能主动访问最新数据；
不能稳定读取企业内部资料；
不能执行外部动作；
不能管理长期任务状态。

所以第零代最核心的问题是：模型能力和现实世界之间断裂。它能想、能说，但不能行动。

这一阶段也出现了第一波泡沫：提示词工程师、提示词模板市场、提示词课程和提示词认证。早期模型确实对 prompt 很敏感，但市场把一个临时补丁误解成了长期护城河。

后来 GPT-4 级别模型、系统提示、函数调用和产品默认引导逐渐成熟，大量提示词模板失去稀缺性。这个现象后来反复出现：新能力出现时，中间层爆发；下一代系统把能力内化后，中间层蒸发。

2023 年中：第一代，工具调用觉醒

第一代 Agent 的关键词是工具调用。

2023 年 6 月，OpenAI 发布 function calling。它允许开发者向模型描述函数名、用途、参数类型和 JSON Schema。模型理解用户请求后，可以不再输出普通自然语言，而是输出一个结构化 JSON 调用，再由外部系统执行。

这一步的架构意义很大：模型开始从“只会说话的大脑”，变成可以驱动外部工具的大脑。

第一代的关键能力包括：

根据用户意图选择工具；
输出结构化参数；
调用外部 API；
把 API 结果带回模型继续推理；
通过 RAG 接入外部知识；
通过插件和知识库形成早期 persona。

同一时期，RAG 和向量数据库流行起来。它们解决的是模型不知道最新信息、企业私有资料和内部知识的问题。系统先检索相关文档片段，再把材料放进上下文，让模型基于这些材料回答。

于是第一代 Agent 的基本结构出现了：

你是谁：系统提示和 persona；
你知道什么：知识库、RAG、私有文档；
你能做什么：函数调用、插件、外部 API。

这一代最典型的泡沫是 AutoGPT。它展示了一个很诱人的想法：用户只给一个宏大目标，AI 自己拆解任务、搜索、写文件、评估、循环，直到它认为完成。

但 AutoGPT 很快暴露问题。它缺少状态约束、终止条件和可靠反馈，经常陷入错误方向，反复调用错误参数，或者烧掉大量 API 请求。第一代的教训很直接：工具加死循环，不等于生产级 Agent。

2023 年末到 2024 年：第二代，工程化工作流

AutoGPT 的失败让行业意识到，不能只靠模型自由发挥。复杂任务需要结构化流程。

第二代 Agent 的关键词是工程化工作流。Agent 不再只是一次模型调用，而是一个有状态、有控制流、有评估机制的软件系统。

这一代的关键能力包括：

任务规划：把大目标拆成步骤；
状态管理：记录任务进行到哪里；
反思修正：生成后自评，再修改；
工具编排：在不同工具之间切换；
人机协作：在关键节点让人确认；
多 Agent 协作：让不同角色分工。

典型范式是 ReAct，也就是 Reasoning + Acting。模型先推理，再调用工具，再根据观察结果进入下一轮推理。这样 Agent 不再盲目行动，而是每一步都有可审计的逻辑和反馈。

这一阶段也形成了 agentic workflow 的几种常见模式：

反思：先生成，再评审，再修改；
工具调用：按任务选择搜索、数据库、代码执行、企业 API；
规划：拆解目标，跟踪状态；
多 Agent 协作：产品、开发、测试、评审分工。

第二代的价值，是把模型能力放进可控流程里。一个设计好的 workflow，有时能让较小模型完成比单次大模型调用更稳定的结果。

但这一代也带来低代码 Agent 平台泡沫。很多平台用拖拽方式组合 prompt、RAG、插件和流程，确实降低了搭建门槛。但如果一个流程可以被低成本复制，平台本身就很难形成护城河。

低代码工具能吃到早期红利，但红利不等于壁垒。

2024 到 2025 年：第三代，Computer Use 进入真实界面

第三代 Agent 的关键词是 Computer Use。

此前的工具调用主要依赖 API，能做什么取决于开发者提前接好什么接口。但现实世界里，大量软件没有理想 API，或者 API 不开放、不完整、不统一。

Computer Use 类能力让模型开始看屏幕、点鼠标、操作 GUI。它把通用电脑界面本身变成工具。

第三代的关键能力包括：

识别屏幕内容；
点击按钮、输入文本、切换窗口；
操作网页和桌面软件；
读仓库、改文件、跑测试；
查看终端输出和错误信息；
更接近真实工程助手。

这一步把 Agent 从“调用已接好的工具”，推进到“像人一样操作软件界面”。它也让 coding agent 更接近真实工作流：读项目、改代码、运行测试、根据报错继续修。

但信任边界也扩大了。AI 操作电脑，意味着它可能误点、误删、误提交，也可能被网页、文档或界面文字诱导。提示注入不再只是聊天问题，而可能变成文件操作、权限和系统安全问题。

Vibe coding 的争议也集中在这一阶段。让 AI 快速生成项目很爽，但如果缺少测试、评估、权限控制和部署边界，就容易从快速原型变成快速事故。

第三代的核心教训是：越接近真实操作，越需要沙箱、审批、回滚和最小权限。

2025 到 2026 年：第四代，MCP、Skills 和常驻数字员工

第四代 Agent 的关键词是常驻、连接、记忆和专业化。

这一代的重点不只是单次任务更强，而是 Agent 开始拥有长期上下文、工具网络、专业技能和时间感。它不再只是一次聊天里的助手，而更像一个能持续工作的数字员工。

MCP 解决的是工具连接问题。它让 Agent 用标准方式连接文件系统、数据库、浏览器、设计工具、项目管理工具和企业系统。协议一旦稳定，很多只做“工具连接中间层”的项目就会被压缩。

Skills 解决的是专业方法问题。工具告诉 Agent 能做什么，技能告诉 Agent 应该怎么做。一个好的 skill 不只是 prompt，而是把领域流程、约束、检查方式、常见坑和工具调用顺序封装起来。

第四代的关键能力包括：

长期记忆：保存用户偏好、项目规则和历史任务；
项目上下文：让 Agent 理解代码库、文档和工作规范；
工具网络：通过 MCP、API、浏览器和文件系统连接外部世界；
专业技能：用 Skills 封装任务方法；
常驻执行：可以等待、唤醒、提醒和继续跟进；
远程协作：用户可以从不同设备回来审批和调整。

这一代 Agent 开始有“员工感”：

有身份和职责边界；
有长期上下文；
有专业工作方法；
有时间感；
有工具权限；
能在无人盯着时继续推进任务。

但能力越像员工，风险半径也越像员工。长期运行、读取本地数据、持有密钥、调用工具、处理任务，都让安全问题从边缘变成中心。

尤其要注意一点：文本也是攻击面。如果 Agent 会读取并遵循 Markdown、说明文档、技能包、网页内容，那么恶意文本就可能改变它的行为。提示注入不再只是聊天问题，而是供应链问题、权限问题和执行安全问题。

第四代的核心教训是：常驻 Agent 不只需要能力，还需要治理。

2026 之后：第五代前瞻，闭环、内在记忆和世界模型

第五代还不是确定历史，更像是沿着前面四年的演进逻辑继续外推。

第一个方向是更完整的闭环。

成熟 Agent 至少需要三层闭环：

执行闭环：每一步操作后验证结果，不符合预期就回滚、修正、重试；
时间闭环：跨多个唤醒周期追踪长期目标，而不是做完一次动作就结束；
认知闭环：知道哪些信息确定，哪些只是猜测，哪些已经过期。

第二个方向是内在记忆。

过去的记忆大多在模型外部：RAG、向量库、会话记录、本地文件、memory.md。如果未来模型架构本身支持跨会话持久状态，Agent 的记忆系统会被重构。

第三个方向是世界模型。

今天很多 Agent 仍是反应式的：观察、响应、再观察。真正高风险任务需要模型能预演行动后果。比如改数据库脚本前，要先想到数据丢失、回滚失败、兼容性问题，而不是先造成事故再学习。

第四个方向是具身化。

前几代主要发生在数字空间：API、屏幕、文件、浏览器、企业工具。下一步可能是把 Agent 的行动能力延伸到物理世界，例如机器人、设备控制、工业系统和标准化物理接口。

第五代真正要解决的问题，是如何让 Agent 不只会执行任务，还能理解行动后果、管理长期状态，并在更大风险半径内保持可靠。

这条时间线背后的六条规律

第一，基座模型能力仍然是天花板。Agent 不是大模型之外的魔法，而是大模型能力通过工程系统释放出来的方式。

第二，工程化架构会放大模型能力。规划、验证、反思、修正、评估和权限控制，比单次生成更接近可交付结果。

第三，开放协议会重塑价值分配。MCP、Skills、项目上下文规范一旦稳定，竞争焦点会从“谁先接了工具”转向“谁沉淀了真实领域能力”。

第四，Agent 演化的隐含主线是人机信任边界扩展。从信任文本，到信任 API 调用，到信任复杂工作流，到信任电脑操作，再到信任常驻执行，每一代都把风险半径往外推。

第五，每一代事故都会变成下一代铁律。AutoGPT 的无限循环推动结构化编排，vibe coding 的失控推动评估驱动开发，误删生产环境推动最小权限和沙箱，技能投毒推动供应链安全。

第六，Agent 生态会反复经历爆发和灭绝。能力升级会创造临时中间层，模型或平台内化后又会消灭这些中间层。把时间窗口误判成护城河，是 AI 创业里很危险的错觉。

真正的护城河

AI Agent 领域真正的护城河，不是抢先包装某个新能力。

更可靠的护城河大概有三类。

第一，垂直领域深度。你是否真的理解一个行业的流程、风险、异常和责任边界。通用模型可以学概念，但不一定能替代长期打磨出来的领域执行经验。

第二，数据飞轮。你是否能从真实使用中积累高质量反馈，不断改进流程、评估、微调和产品判断。

第三，用户信任。用户是否愿意把更高价值、更长期、更有风险的任务交给你，而不是只把你当成一次性工具。

当某项能力被平台或基座模型吞噬之后，仍然能沉淀流程、反馈、责任边界和信任的产品，才更可能留下来。除此之外，很多项目只是阶段性泡沫。

最后

从 2022 年到 2026 年，AI Agent 的演进不是“模型越来越会聊天”，而是“人类愿意交给 AI 的事情越来越多”。

真正成熟的 Agent，不是最敢自动执行的系统，而是知道何时执行、何时验证、何时暂停、何时请人确认的系统。

如果要判断一个 Agent 产品是否有长期价值，可以问一个问题：当这个能力被下一代模型或平台内置后，它还剩下什么？

答案如果是领域流程、真实数据、可验证结果和用户信任，那才可能是长期价值。

Gemini 3.5 Pro 提前曝光：谷歌想用 Spark Agent 抢回 AI 编程入口

Fri, 15 May 2026 23:45:34 +0800

Gemini 3.5 Pro 还没正式发布，相关爆料已经开始升温。

这轮信息里有几个关键词：Gemini 3.5 Pro、代号 Cappuccino、Gemini Spark、AI 编程、MCP 工具接入。它们指向同一个方向：谷歌不只是想更新一个聊天模型，而是想把模型、工具、Agent 和 Google 生态入口重新绑在一起。

不过，在正式发布前，这些信息都应该按“爆料”看待。真正值得关注的不是某一张截图或某一个跑分，而是谷歌接下来可能要补的几块短板。

Gemini 3.5 Pro 为什么值得关注

从曝光信息看，Gemini 3.5 Pro 可能是一次跳级命名。

此前外界还在讨论 Gemini 3.2，随后又出现 Gemini 3.5 Pro 的说法。如果命名属实，说明谷歌想在新一轮发布里讲一个更大的版本故事，而不是只做常规小更新。

目前流出的重点主要集中在三方面：

编程和推理能力继续提升；
SVG、交互式页面、动画和 3D 生成能力增强；
新的 Agent 产品 Gemini Spark 可能进入前台。

这些方向并不意外。Gemini 系列一直强调多模态，谷歌也有足够强的分发渠道。真正的问题是，它能不能在开发者工具和 Agent 工作流上赶上 OpenAI、Anthropic 的节奏。

编程能力是谷歌最需要补的课

大模型竞争进入 2026 年后，编程已经不只是“模型能力测试项”，而是最直接的产品入口。

原因很简单：AI 编程工具有高频使用场景，也能产生大量可反馈的数据。开发者每天让模型读代码、改代码、跑测试、修 bug，这些交互天然会推动下一代模型和工具链继续进化。

过去一年，Claude Code 在开发者群体里声量很高，OpenAI 也持续强化 Codex 与 ChatGPT 的协同。相比之下，谷歌虽然有 Antigravity 等产品，但外部存在感并不算强。

这也是 Gemini 3.5 Pro 被重点观察的原因。如果它只是聊天更强、回答更快，意义有限；如果它能真正改善代码理解、跨文件修改、工具调用和长任务执行，才可能改变开发者工作流。

Gemini Spark 可能是更大的变量

比模型本身更激进的，是传闻中的 Gemini Spark。

按照曝光描述，Spark 的定位不是普通聊天助手，而是全天候运行的 AI Agent。它可能接入邮件、日程、网页、任务、账号状态和个人上下文，帮助用户处理多步骤工作流。

这类产品的想象空间很大。比如：

自动整理收件箱；
帮用户跟进任务；
在网页上执行操作；
处理跨应用流程；
根据个人偏好安排日常事务。

但风险也同样明显。一个全天候 Agent 如果能访问登录状态、浏览器数据、文件、位置和第三方服务，就必须回答几个问题：什么时候需要用户确认？哪些操作必须禁止自动执行？数据会不会被共享给第三方？远程浏览器和凭证如何隔离？

所以 Spark 真正的看点，不只是“能不能帮你干活”，而是谷歌能否把权限、审计、确认机制和用户控制做得足够清楚。

MCP 工具接入说明什么

爆料里还提到，新的 Gemini 选择器可能出现 MCP 相关模型或测试入口。

如果这部分最终落地，说明谷歌也在把模型从“问答系统”推向“工具操作系统”。模型不再只是生成文本，而是要能调用外部工具、访问业务系统、读写文件、执行命令，并在多个步骤之间保持任务状态。

这和 OpenAI、Anthropic 的方向是一致的。谁能让模型更稳定地调用工具，谁就更容易把 AI 嵌进真实工作流。

不过，MCP 接入本身不是终点。真正难的是稳定性：

模型能否正确选择工具；
参数是否可靠；
失败后能不能恢复；
权限边界是否明确；
用户能不能追踪每一步操作。

如果这些问题没解决，工具越多，出错面也越大。

多模态仍然是谷歌的优势牌

谷歌最有机会打出差异化的地方，仍然是多模态。

从曝光的 SVG、交互式页面、动画和视觉生成案例看，Gemini 可能继续强化“从提示词生成可交互内容”的能力。相比单纯写一段代码，这更接近产品原型生成：用户描述一个想法，模型直接给出可操作、可调节、可预览的界面。

这条路线很适合谷歌。它既能承接 Gemini 的多模态能力，也能和 Android、Chrome、Workspace、搜索、广告、云服务等入口结合。

如果谷歌想避免只在“谁的代码模型更强”上硬拼，它很可能会把重点放到更完整的多模态 Agent 系统上。

三家公司的打法正在分化

现在的大模型竞争已经不是单一模型排行榜竞争。

OpenAI 的优势在产品迭代和分发节奏，Codex、ChatGPT、企业工具和 API 之间的联动越来越紧。

Anthropic 的优势在开发者心智和代码模型质量，Claude Code 已经成了很多人默认的 AI 编程入口。

谷歌的优势则是生态入口。Gmail、Docs、Chrome、Android、搜索、YouTube、地图和云服务构成了一个巨大的个人与企业数据网络。只要 Agent 能安全接入这些入口，谷歌就有机会从“模型追赶者”变成“工作流入口控制者”。

这也是 Gemini Spark 值得关注的原因。它不一定需要在所有基准测试上第一，但只要能进入日常工作流，就可能形成自己的护城河。

普通用户该怎么看

对普通用户来说，短期不必被每一次爆料牵着走。

更实用的观察点有三个：

Gemini 3.5 Pro 的编程能力是否真的改善，尤其是复杂仓库、长上下文和工具调用。
Gemini Spark 是否默认安全，敏感操作前是否有明确确认和可追踪记录。
谷歌是否给出清晰价格、额度和企业权限管理，而不是只展示演示效果。

如果只是生成几张漂亮截图，价值有限。能不能稳定接入真实工作流，才是这一轮 AI Agent 产品的分水岭。

对开发者意味着什么

开发者最应该关注的不是“哪个模型赢了”，而是自己的工作流是否可迁移。

现在 Claude Code、Codex、Gemini、Antigravity、Cursor、Windsurf 等工具都在抢入口。如果把所有流程都绑死在某一个平台上，未来成本、额度、模型策略或权限规则一变，迁移会很痛。

更稳妥的做法是：

重要项目保留标准 Git 工作流；
自动修改后必须看 diff；
关键任务用测试和 CI 兜底；
不把生产凭证交给不透明 Agent；
能用开放协议接工具时，优先选择可替换方案。

模型会继续变强，但工程纪律不会过时。

小结

Gemini 3.5 Pro 的爆料说明，谷歌正在加速补齐 AI 编程和 Agent 入口。模型能力提升是一部分，Gemini Spark 这类全天候 Agent 可能才是更大的战略动作。

但越是能帮用户“自动干活”的系统，越需要严格的权限边界和可验证流程。对谷歌来说，真正的挑战不只是追上 GPT-5.5 或 Claude，而是把强模型、安全机制和生态入口组合成一个可信的日常工作流。

如果这一步做成，Gemini 不一定要在每个榜单上第一，也可能重新拿回一部分 AI 入口主动权。

OpenHuman 速读：开源个人 AI Agent 的桌面化路线

Fri, 15 May 2026 14:52:31 +0800

OpenHuman 是 tinyhumansai 推出的开源个人 AI Agent 项目。它的目标不是再做一个聊天窗口，而是把桌面应用、个人记忆、第三方集成、语音、编码工具和本地知识库放进同一个 agent harness 里，让 AI 更快理解你的日常工作上下文。

项目 README 给它的定位是 “Personal AI super intelligence”，官网也强调 private、simple 和 extremely powerful。这个说法很有野心，但更适合拆开看：OpenHuman 真正值得关注的地方，是它试图把“个人上下文”作为产品核心，而不是把模型调用、插件配置和文档检索留给用户自己拼。

截至本文查看时，GitHub 仓库约有 7.8k stars、629 forks，最新 release 显示为 OpenHuman v0.53.43，时间是 2026 年 5 月 13 日。项目仍处在 Early Beta，README 明确提醒正在活跃开发中，应该预期会有粗糙边缘。

它想解决什么问题

很多 AI 助手的问题不是模型不够强，而是上下文太冷。你每次都要重新解释项目背景、最近邮件、日程、代码仓库、文档、任务和偏好；一旦跨到 Gmail、Notion、GitHub、Slack、Calendar、Drive、Linear、Jira 这些系统，信息又被拆散到不同工具里。

OpenHuman 的思路是：先把这些数据接进来，再通过自动抓取、压缩、摘要和本地知识库，构建一个可以持续更新的个人记忆层。这样 agent 不是只记得当前对话，而是能围绕你的工作流形成长期上下文。

这也是它和普通聊天机器人最大的差异。聊天机器人往往围绕 prompt 工作；OpenHuman 更像一个桌面端个人操作系统入口，试图把连接器、记忆、工具和模型路由都预先打包。

主要能力

OpenHuman README 里列出的核心能力包括：

桌面优先的 UI 和较短的上手路径，不要求用户先从终端配置开始。
一个带“脸”的桌面 mascot，可以说话、响应环境，并参与 Google Meet。
118+ 第三方集成，覆盖 Gmail、Notion、GitHub、Slack、Stripe、Calendar、Drive、Linear、Jira 等工具。
自动抓取机制：项目描述中提到每 20 分钟遍历活跃连接，把新数据拉入 memory tree。
Memory Tree：把连接数据和活动信息压缩成 Markdown 块，并存入本地 SQLite。
Obsidian-compatible vault：把知识块落成 .md 文件，用户可以用 Obsidian 打开、浏览和编辑。
内置搜索、网页抓取、编码工具、文件系统、git、lint、test、grep、语音输入输出等能力。
Model routing：按任务把请求路由到不同模型类型。
TokenJuice：在工具结果、网页抓取、邮件正文、搜索结果进入 LLM 前做 token 压缩。
可选 Ollama，用于本地 AI 工作负载。

这些能力听起来很多，真正的重点可以归纳成两条：一是减少配置和插件拼装；二是把你的个人数据变成 agent 可检索、可压缩、可持续更新的记忆。

安装方式

项目提供网站下载入口，也给了终端安装命令。

macOS 或 Linux x64：

`1`	`curl -fsSL https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.sh \| bash`

Windows：

`1`	`irm https://raw.githubusercontent.com/tinyhumansai/openhuman/main/scripts/install.ps1 \| iex`

如果是日常主力机，建议先从官网下载安装包，或者至少先打开安装脚本检查内容，再决定是否直接执行远程脚本。OpenHuman 涉及邮箱、文档、代码仓库、日历和本地文件权限，安装和授权都应该比普通小工具更谨慎。

开源和技术栈

OpenHuman 仓库采用 GPL-3.0 license。仓库语言占比显示 Rust 为主，TypeScript 次之，另外还有 JavaScript、Shell、CSS 和 PowerShell。README 的贡献说明要求 Node.js 24+、pnpm 10.10.0、Rust 1.93.0、CMake，以及平台相关桌面构建依赖。

本地开发的大致路径是：

git submodule update --init --recursive
pnpm install
pnpm dev
pnpm --filter openhuman-app dev:app

提交前推荐跑 focused checks，例如：

1
2
3

pnpm typecheck
pnpm format:check
cargo check -p openhuman --lib

从目录结构看，它不是一个轻量脚本项目，而是包含桌面应用、前端、Rust 后端、文档、测试、示例和构建脚本的完整产品型仓库。

Memory Tree 和 Obsidian vault 为什么重要

OpenHuman 里最值得单独看的概念是 Memory Tree。README 描述它会把连接进来的数据标准化成不超过约 3k token 的 Markdown chunks，打分后折叠进层级摘要树，并存入本机 SQLite。相同内容也会进入 Obsidian 兼容 vault。

这条路线有几个好处：

用户可以直接看到 agent 的知识库，而不是只能相信黑盒记忆。
Markdown 文件方便搜索、备份、版本管理和人工修订。
SQLite 适合本地索引和快速查询。
层级摘要比一堆平铺文档更适合长期上下文压缩。

但它也有现实挑战：数据同步是否稳定、摘要是否会丢关键细节、权限边界是否足够清晰、删除和撤销是否完整、不同连接器的语义是否能被一致处理。这些都不是 README 里一句 “remembers everything” 就能解决的，需要长期使用和审计才能判断。

TokenJuice：成本和延迟的中间层

OpenHuman 还强调 TokenJuice。它的作用是在网页、邮件、搜索结果和工具调用结果进入模型前做压缩，例如把 HTML 转成 Markdown、缩短长 URL、移除部分非必要字符等。README 宣称这可以减少成本和延迟，最高降低 80% token 使用。

这个方向是合理的。Agent 系统真正烧钱的地方，往往不是一次聊天，而是后台抓取、工具调用、搜索、网页解析和长上下文注入。把数据先清洗再交给模型，通常比直接塞原始内容更稳。

不过压缩层也会带来新问题：它会决定哪些信息被保留，哪些被丢弃。如果你用它处理合同、账单、医学记录、合规材料或生产事故日志，就不能只看 token 节省，还要看可追溯性、原文回查和压缩误差。

隐私：卖点也是审查重点

OpenHuman 的卖点之一是 private。官网提到本地 AI 模型可处理低级任务，README 也强调 workflow data stays on device、encrypted locally、treated as yours。

这类设计方向很吸引人，因为个人 AI Agent 一旦接入 Gmail、Drive、Calendar、Slack、GitHub，就会碰到最敏感的工作数据。相比完全云端的助手，本地优先的记忆层和可见的 Markdown vault 至少给了用户更多控制感。

但也要把话说完整：OpenHuman 同时提到 one subscription、30+ providers、model routing、ElevenLabs TTS、OAuth integrations 等能力。这意味着它不是纯离线工具。真正评估隐私时，需要看每个连接器、每类模型调用、每个语音和搜索能力分别把什么数据送到哪里。

适合谁关注

OpenHuman 现在更适合三类人：

想要个人 AI 操作台，而不是单点聊天机器人的用户。
愿意尝试 Early Beta，并能接受功能变化和粗糙边缘的开发者。
关注本地记忆、Obsidian 工作流、agent connector 和上下文压缩的人。

如果你只是想找一个稳定、轻量、隐私边界极简的离线助手，那它目前可能太重。如果你想研究下一代个人 AI Agent 会如何整合桌面、连接器、记忆和工具，OpenHuman 则是一个值得跟踪的开源样本。

我的建议是先把它当成“产品型开源实验”观察：看 release 节奏、issue 质量、连接器权限、数据导出能力、删除机制和本地 vault 的可读性。个人 AI 的关键不只是能不能回答问题，而是它是否能长期、透明、可控地承载你的上下文。

参考链接

Codex /goal vs Claude Code /goal：长任务自动跑到完成

Thu, 14 May 2026 22:22:42 +0800

/goal 正在变成 AI 编程工具里的一个重要命令。

它解决的不是“让模型多写几行代码”，而是另一个更实际的问题：当任务有明确完成条件时，能不能让 Agent 持续推进，直到条件满足，而不是每完成一轮就停下来等用户继续催。

Codex CLI 已经在官方文档里加入了实验性的 /goal。Claude Code 也上线了自己的 /goal 文档，而且把它描述成一种可以跨多轮持续工作的自动化能力。两者名字一样，但产品取向并不完全一样。

`/goal` 到底解决什么问题

普通 AI 编程对话通常是“一问一答”：

用户提出任务。
Agent 分析、改代码、跑测试。
Agent 汇报结果。
用户再决定下一步。

这个流程适合短任务，但遇到迁移、重构、测试修复、issue backlog 清理时，就会变得很碎。Agent 可能每次只推进一小段，然后停下来等你输入“继续”。

/goal 的思路是把任务从“下一步做什么”改成“最终什么状态算完成”。例如：

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

这类目标天然适合长任务，因为它有清楚的终点：测试通过、构建成功、文件拆分完成、队列清空、验收条件满足。

Codex 的 `/goal`：实验功能，绑定当前线程

OpenAI 的 Codex CLI 文档把 /goal 标为实验功能。它不是默认稳定能力，需要先开启 features.goals。

开启方式有两种：

`1`	`/experimental`

或者在 config.toml 里加入：

1
2

[features]
goals = true

启用后，可以这样使用：

`1`	`/goal Finish the migration and keep tests green`

常用命令包括：

/goal
/goal pause
/goal resume
/goal clear

按照 OpenAI 文档的说法，Codex 会把 goal 附着在当前 active thread 上，在更大的任务运行过程中持续跟踪这个目标。

这里要注意一个细节：官方文档对 Codex /goal 的措辞比较克制。它强调“给长任务设置实验性目标”“把目标附着到当前线程”，但没有像 Claude Code 文档那样展开说明每一轮结束后由独立 evaluator 自动判断并继续下一轮。所以现在使用 Codex /goal 时，最好仍把它看作实验中的长任务目标机制，而不是完全稳定的无人值守执行模式。

Claude Code 的 `/goal`：完成条件驱动的多轮执行

Claude Code 的 /goal 文档写得更明确：用户设置 completion condition 后，Claude 会跨 turn 持续工作，直到条件满足。

示例：

`1`	`/goal all tests in test/auth pass and the lint step is clean`

Claude Code 的机制大致是：

当前 turn 完成后，不直接把控制权还给用户。
一个小型快速模型会检查目标条件是否已经满足。
如果没有满足，Claude 自动开始下一轮。
如果满足，goal 自动清除，并在 transcript 里记录完成状态。

这意味着 Claude Code 的 /goal 更像“按完成条件自动续跑”。它不只是把目标挂在会话里，而是把“是否继续下一轮”交给一个独立评估步骤。

Claude Code 还支持直接查看状态：

/goal

状态里会显示目标条件、运行时间、已评估 turn 数、token 消耗，以及 evaluator 最近一次给出的原因。

如果要提前停止，可以使用：

`1`	`/goal clear`

stop、off、reset、none、cancel 也可以作为清除别名。开启目标后，如果会话中断，之后通过 --resume 或 --continue 恢复时，仍然 active 的 goal 可以被带回来；但计时、turn 数和 token 基线会重新计算。

两者最大的差异

Codex 和 Claude Code 都在把 AI 编程从“单轮回答”推向“长任务执行”，但 /goal 的定位有差异。

对比项	Codex CLI `/goal`	Claude Code `/goal`
状态	experimental	官方文档单独成页说明
启用方式	需要开启 `features.goals`	可直接在受信任 workspace 使用
目标作用域	当前 active thread	当前 session
常用操作	set / view / pause / resume / clear	set / view / clear
自动判断	文档强调目标附着与跟踪	明确说明每轮后由 evaluator 判断
自动续跑	文档表述较克制	条件未满足时自动下一轮
适合场景	想在 Codex 长任务里保持目标上下文	想按完成条件让 Claude Code 持续推进

简单说，Codex 的 /goal 更像“给当前线程挂一个实验性的长期目标”；Claude Code 的 /goal 更像“给当前会话设置一个可验证的停止条件，让它自动干到满足为止”。

写好 `/goal` 的关键

不管使用哪一个工具，/goal 都不适合写成模糊愿望。

不太好的写法：

`1`	`/goal 把项目优化一下`

更好的写法：

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

一个好目标通常包含三点：

明确的完成状态。
可执行的验证方式。
必须遵守的边界。

如果目标太大，还应该加上停止条件：

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

这很重要。/goal 越强，越需要边界。否则 Agent 可能会为了追求“完成”而改动过多文件、跑太久、消耗太多 token，甚至把原本该停下来询问的问题继续往前推。

什么时候适合用 `/goal`

适合：

测试修复：直到指定测试通过。
代码迁移：直到所有调用点改完并编译成功。
批量清理：直到某类 lint 或类型错误清零。
文档补齐：直到所有指定模块都有说明。
issue 队列处理：直到某个标签下的问题都被处理或明确分类。

不适合：

需求本身还没想清楚。
需要频繁产品判断。
涉及高风险删除、数据迁移或权限变更。
验收条件只能靠主观判断。
任务会跨越大量无关模块。

一个实用原则是：如果你能写出“跑哪个命令、看到什么结果、哪些文件不能碰”，就适合用 /goal。如果只能写“帮我做得更好”，那还是先用普通对话、计划模式或人工评审更稳。

对 AI 编程工具的影响

/goal 代表一个很明显的方向：AI 编程工具正在从“交互式助手”变成“可持续执行的工作单元”。

过去我们让 Agent 做任务，经常要在旁边守着。它卡住了要提示，测完了要继续，报错了要再下命令。/goal 把这部分交互压缩成一个完成条件，让 Agent 自己决定下一轮该做什么。

但这也带来新的要求。以后写 prompt 不只是描述任务，还要写验收条件、验证命令、修改边界和停止规则。换句话说，用户的工作从“催它继续”变成“定义什么叫完成”。

Codex 和 Claude Code 走到 /goal 这一步，说明长任务 Agent 已经不再只是后台任务或云端队列的专利。终端里的本地编程工具，也开始需要更强的自主推进能力。

总结

Codex CLI 和 Claude Code 都有了 /goal，但现阶段不要把它们简单看成同一个功能。

Codex 的 /goal 仍是实验能力，需要开启 features.goals，更适合在 Codex 当前线程里维持长期目标。Claude Code 的 /goal 则更明确地把“完成条件”和“自动续跑”连在一起，通过独立 evaluator 判断是否继续。

对日常开发来说，这类命令最适合处理有明确验收标准的工程任务。它不会替代需求判断，也不会消除代码审查，但能减少长任务里大量重复的“继续”“再跑一次”“修到测试通过”。

真正要学会的不是某个命令本身，而是如何把任务写成清楚、可验证、可停止的目标。

参考资料

OpenAI Codex CLI Slash Commands：https://developers.openai.com/codex/cli/slash-commands
Claude Code Goal 文档：https://code.claude.com/docs/en/goal

AI 编程工具这一轮，DeepSeek 为何成了省钱关键？

Mon, 11 May 2026 04:59:00 +0800

这一轮 AI 编程工具的竞争，表面上是在比模型能力、插件生态和 agent 自动化程度，真正用起来以后，最先撞上的问题却是成本。

Claude Code、Codex、OpenClaw、Superpowers 这类工具都很好用，但它们有一个共同特点：一旦进入复杂任务，就会非常吃 token。它们要读项目、建计划、调用工具、总结上下文、反复检查结果，还可能拉起多个子任务。模型越聪明，工作流越自动化，账单也越容易悄悄变大。

所以 DeepSeek 在这一轮里变得很关键，不只是因为它能写代码，而是因为它在长上下文和缓存成本上，刚好打中了 AI 编程工具最烧钱的地方。

Agent 工具为什么特别费 token

传统聊天式编程助手，通常是一问一答。你问一个函数怎么写，它回答一段代码。这个模式消耗不小，但还算可控。

Agent 工具不一样。它不是只回答问题，而是要像一个临时工程师一样进入项目：

先扫描目录和关键文件；
再理解需求和现有架构；
然后制定计划；
修改文件；
运行命令或测试；
根据报错继续修；
最后总结改了什么。

这个过程里，模型反复读取同一批上下文。项目说明、代码片段、工具结果、历史对话、计划和错误日志都会被塞回上下文。任务稍微复杂一点，几十万 token 很快就出去了。

如果再装一些更激进的插件，成本会更明显。比如有些 OpenCode 或 Claude Code 增强工具，会默认组织一整套 agent 团队。你只是想改一个小功能，它也可能启动规划、审查、执行、复盘等多个环节。任务当然显得更“智能”，但 token 也会一路往上跑。

Superpowers 的好处是按需触发

Superpowers 这类工具的一个优点，是它不会在所有任务里都强行拉起完整 agent 流程。

平时你还是可以让 Claude Code、OpenCode 或 Codex 按原来的方式工作。只有当你明确调用某个 skill，比如头脑风暴、写计划、执行计划、做复盘时，它才进入更重的自动化流程。

这对成本很重要。

AI 编程不应该所有任务都用重武器。改一行配置、查一个报错、写一个小脚本，用普通对话就够了；只有复杂重构、跨文件修改、长文档处理、多轮验证，才值得上完整 agent 流程。

工具越强，越要学会控制触发条件。否则自动化越多，浪费越多。

DeepSeek 的关键优势是缓存便宜

DeepSeek 适合接这类 agent 工具，一个很重要的原因是缓存命中成本低。

AI 编程任务里有大量重复前缀。比如项目背景、系统提示词、工具说明、文件内容、前几轮对话，经常会在后续请求里反复出现。如果模型服务支持 prompt cache，这些重复内容命中缓存后，成本会明显下降。

很多模型的缓存命中价只是比未命中便宜一些，比如便宜到三分之一左右。DeepSeek 的优势在于，命中缓存后的价格差距可以大很多。对长上下文、多轮调用、重复读取项目的 agent 工作流来说，这个差距会直接反映到账单上。

也就是说，DeepSeek 不是每一次回答都一定最强，而是在“长任务、多轮任务、反复读上下文”的场景里，成本结构特别适合 AI 编程。

长上下文让 Claude Code 更好用

把 Claude Code 或类似工具接到 DeepSeek V4 时，另一个明显优势是长上下文。

AI 编程工具最怕上下文不够。上下文一不够，就要频繁压缩；压缩一多，前面读过的细节就可能丢失。模型开始忘记项目结构、忘记约束、忘记某个文件为什么这么改，后续质量就会下降。

DeepSeek V4 系列的长上下文能力，让它更适合处理代码仓库、文档批处理、字幕翻译、站点文章整理这类任务。特别是接入 Claude Code、OpenClaw 这类工具时，如果配置得当，可以让它尽量晚一点进入上下文压缩，让模型保留更多项目细节。

这也是为什么有些任务用 DeepSeek 会显得“很经使”：它不一定每一步都惊艳，但能承受长时间、低成本、反复调用。

V4 Pro 和 V4 Flash 怎么分工

DeepSeek V4 Pro 和 V4 Flash 不应该混着用。

简单任务用 DeepSeek V4 Flash 更合适。它速度快、成本低，用在下面这些场景通常足够：

翻译字幕；
整理文档；
生成普通脚本；
修改小范围代码；
跑 OpenClaw 里的轻量任务；
做简单的站点内容处理。

复杂任务再考虑 DeepSeek V4 Pro：

大规模重构；
多模块代码理解；
复杂推理；
长链路 agent 任务；
高风险代码修改；
需要更强规划能力的工程任务。

很多人一上来就想挂最强模型，这反而不划算。AI 编程工具最现实的玩法，是把任务分层：便宜模型吃掉大量常规工作，贵模型只处理关键节点。

MiniMax、豆包和 DeepSeek 的位置不同

国产模型和套餐里，MiniMax、豆包、Kimi、DeepSeek 各有位置。

MiniMax 的优势是量大、便宜、功能全。它未必是最聪明的编程模型，但拿来做翻译、轻量整理、批处理，很划算。比如批量处理字幕、改格式、做简单校对，MiniMax 这类套餐很耐用。

豆包的优势是生态工具比较全，图片、视频、搜索、TTS、可能的 STT 和 embedding 都能接在一起。它更像综合型工具箱。

DeepSeek 的位置更明确：文本、代码、长上下文、低成本缓存。它没有完整的图像生成、语音、视频生态，短板很明显；但在 AI 编程和长文本 agent 工作流里，它的长板足够长。

所以不是谁替代谁，而是任务拆开以后各用各的。

省钱的关键不是只找便宜模型

AI 编程想省钱，不是简单把所有请求都换成便宜模型。

真正有效的省钱方式有几条：

简单任务不要启动重 agent。
能用 Flash 的任务不要上 Pro。
长任务尽量利用缓存。
重复上下文要稳定，避免无意义改动导致缓存失效。
大任务先让便宜模型做草稿和批处理，再让强模型做关键审查。
明确告诉 agent 不要重复描述事实，不要反复总结同一件事。

尤其是最后一点很重要。AI 工具很容易啰嗦，啰嗦不只是阅读体验问题，也是成本问题。提示词里明确要求“事实只描述一次，观点只表达一次”，能同时改善文章质量和 token 消耗。

DeepSeek 适合哪类 AI 编程工作流

DeepSeek 最适合这些任务：

长代码仓库阅读；
多文件轻量修改；
批量文档整理；
批量字幕翻译；
Hugo 文章整理；
agent 计划执行；
大量重复上下文的低成本自动化。

它不一定适合所有任务。如果要做特别强的前端审美、复杂产品判断、跨模态创作，可能还要搭配 Claude、GPT、Gemini、豆包或其他工具。

但只要任务是“长文本、长上下文、反复调用、成本敏感”，DeepSeek 就很容易变成首选。

小结

AI 编程工具这一轮，DeepSeek 的价值不只是“国产模型能写代码”，而是它解决了 agent 工具最现实的痛点：长任务太烧钱。

Claude Code、OpenClaw、Superpowers 这类工具会让开发流程越来越自动化，但自动化的背后是大量上下文读写和多轮调用。谁能把这部分成本压下来，谁就能让 AI 编程从“偶尔爽一下”变成“天天用得起”。

DeepSeek 的长上下文、低缓存成本和 V4 Flash / V4 Pro 分层使用，正好让它站在这个位置上。

这一轮真正省钱的关键，不是不用好模型，而是把好模型、便宜模型、缓存和 agent 流程搭配好。能把这套账算明白，AI 编程工具才真的会变成生产力，而不是一个漂亮但昂贵的玩具。

goose：桌面端、CLI 和 API 一体的开源 AI Agent

Fri, 08 May 2026 13:35:45 +0800

goose 是一个运行在本机的开源 AI Agent。它不只面向代码补全，而是希望覆盖代码、研究、写作、自动化、数据分析等更广的任务。项目 README 里的定位很直接：桌面端、CLI 和 API 都提供，既可以给普通用户使用，也可以嵌入到自己的工作流里。

这个项目已经从 block/goose 迁移到 Linux Foundation 旗下的 Agentic AI Foundation（AAIF）。当前仓库是：

`1`	`https://github.com/aaif-goose/goose`

goose 主要由 Rust 和 TypeScript 编写，许可证为 Apache-2.0。GitHub 项目描述是：一个开源、可扩展的 AI agent，不只给出代码建议，还能安装、执行、编辑和测试，并可接入任意 LLM。

goose 解决什么问题

很多 AI 编程工具只停留在“给建议”或“改代码”这一层。goose 的目标更宽一些：让 AI agent 直接在你的机器上完成任务。

它可以用于：

代码修改和测试。
本地自动化任务。
资料研究和写作。
数据分析。
多步骤工作流。
通过 API 嵌入到其他系统。
通过 MCP 扩展外部工具能力。

如果你只想在编辑器里要几段代码，普通 Copilot 类工具已经够用。goose 更适合想把 AI 放进“本机任务执行链”的用户：它可以使用本地环境、连接模型 provider、调用扩展，并通过桌面端或 CLI 进入不同工作方式。

三种入口：桌面端、CLI、API

goose 的一个特点是入口比较完整。

第一种是桌面端。它支持 macOS、Linux 和 Windows，适合不想一直待在终端里的用户，也适合需要更清晰可视化交互的人。

第二种是 CLI。终端用户可以直接安装命令行工具，把 goose 放进日常开发流程里。

第三种是 API。它可以作为可嵌入的 agent runtime，让其他系统或内部工具调用 goose 的能力。

这三个入口对应不同使用习惯。个人开发机可以先从桌面端或 CLI 开始；团队内部工具、自动化平台或实验型 agent 工作流，则更适合看 API 和自定义分发能力。

安装方式

官方 README 推荐先下载桌面端：

`1`	`https://goose-docs.ai/docs/getting-started/installation`

如果只安装 CLI，可以使用官方脚本：

`1`	`curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh \| bash`

GitHub Releases 也提供不同平台的构建产物。当前 latest release 信息显示，v1.33.1 发布于 2026-04-29，包含 macOS、Linux、Windows、deb、rpm、Flatpak 等资产。

安装完成后，建议先按官方 Quickstart 配置 provider，再从一个低风险目录开始测试。由于 goose 可以执行本机任务，不建议一开始就在重要生产仓库里给它过高权限。

支持的模型和 provider

goose 支持 15+ provider。README 中列出的方向包括：

Anthropic
OpenAI
Google
Ollama
OpenRouter
Azure
Bedrock
更多 OpenAI-compatible 或云端 provider

它既可以使用 API key，也可以通过 ACP 使用已有的 Claude、ChatGPT 或 Gemini 订阅。

ACP 这一点值得关注。很多用户已经有模型订阅，但不同工具要么不支持直接复用，要么配置方式很割裂。goose 通过 ACP provider 把订阅模型接入 agent 工作流，能减少“订阅在一边、自动化工具在另一边”的割裂感。

不过 provider 政策变化很快。真正使用前，仍然要确认对应服务是否允许这种接入方式、是否有额度限制、是否适合公司代码或敏感数据。

MCP 扩展能力

goose 支持通过 Model Context Protocol（MCP）连接扩展。README 提到它可以连接 70+ extensions。

MCP 的意义在于：agent 不只会“聊天”和“改文件”，还能通过标准协议接入更多工具，比如文档、数据库、浏览器、内部系统、搜索服务、设计工具或项目管理系统。

对个人用户来说，MCP 可以让 goose 连接常用工具。对团队来说，MCP 更像一个安全边界和集成标准：你可以把内部能力包装成 server，让 agent 通过明确接口访问，而不是直接把所有系统暴露给模型。

与代码助手的区别

goose 不只是代码补全工具。更准确地说，它是一个本机 agent runtime。

代码助手通常重点在：

补全代码。
解释代码。
生成函数。
在编辑器里修改局部文件。

goose 更强调：

本机任务执行。
多步骤工作流。
provider 可切换。
扩展能力。
桌面端和 CLI 并存。
API 可嵌入。
不限定在代码任务。

这也意味着它的复杂度更高。你需要考虑模型配置、权限、扩展、工作目录、日志、凭据管理等问题。它不是“越自动越好”的工具，而是更适合被认真配置和逐步引入。

自定义分发

goose 仓库提供 CUSTOM_DISTROS.md，说明可以构建自己的 goose distro，预配置 provider、extensions 和 branding。

这对团队或组织很有意义。

比如团队可以做一个内部版本：

预置公司允许的模型 provider。
默认连接内部 MCP server。
配好安全策略和日志设置。
限制不允许使用的外部服务。
使用自己的品牌和默认引导。

这样普通成员不需要从零理解所有配置，也能减少把 key、provider、扩展配错的风险。

使用建议

如果你第一次尝试 goose，可以按这个顺序来：

先安装桌面端或 CLI。
配置一个你确定可用的 provider。
在测试目录里运行简单任务。
观察它会读取哪些文件、执行哪些动作。
再接入 MCP extension。
最后再尝试复杂代码仓库或自动化工作流。

不要一开始就把 goose 放进生产仓库、给它全部权限、再让它执行模糊任务。AI agent 的能力越强，越需要明确边界。

建议保持几个习惯：

重要改动前先提交 git。
不把 API key 写进项目文件。
只在可信 workspace 里启用高权限操作。
公司代码先确认数据合规和 provider 政策。
对自动化结果保留人工 review。

适合谁用

goose 更适合这些用户：

想要桌面端和 CLI 都可用的 AI agent。
希望使用多个模型 provider。
想通过 MCP 接入更多工具。
需要把 AI agent 嵌入自动化流程。
想在代码之外处理研究、写作、数据分析等任务。
团队希望构建带预配置的内部 agent 分发版。

如果你的需求只是“在 IDE 里补全代码”，goose 可能显得重。
如果你想要一个可以长期扩展的本机 agent 平台，它的设计会更有吸引力。

小结

goose 是 AAIF/Linux Foundation 旗下的开源 AI Agent，定位比传统代码助手更广。它提供桌面端、CLI 和 API，支持 15+ provider、ACP 订阅接入和 70+ MCP extensions，适合把 AI 放进本机工作流和团队自动化体系里。

它的价值不只是“能写代码”，而是把模型、工具、扩展和执行环境放在同一个 agent 框架下。使用时要特别注意权限、凭据和数据边界：先从小任务开始，确认 provider、扩展和执行行为都符合预期，再逐步扩大使用范围。

参考资料

Claude Code 24 个使用技巧：计划模式、回滚、CLAUDE.md、Skills、Agents 和插件

Fri, 08 May 2026 08:54:14 +0800

Claude Code 不只是一个聊天框。它更像一个能进入项目目录、读写文件、执行命令、维护上下文的编程 Agent。

如果只是把需求丢进去让它生成代码，很快会遇到几个问题：计划不够清楚、权限反复确认、上下文越来越长、生成结果不满意、不知道怎么回滚，也不知道怎么把项目规则长期保存下来。

下面整理一组常用操作，适合刚开始使用 Claude Code 的开发者快速建立工作流。

先在项目目录启动

Claude Code 最好在项目目录里启动，而不是随便打开一个终端就开始用。

可以先创建一个文件夹作为项目目录，进入目录后打开命令行，再启动 Claude Code：

claude

首次进入项目时，如果 Claude Code 询问是否信任当前文件夹，确认后再继续。这样它才能围绕当前项目读取文件、创建文件和执行后续操作。

一个简单的练习方式是让它创建一个摄影师个人网站。这个任务足够直观：能看到页面效果，也能练习文件生成、命令执行、回滚和后续重构。

计划模式先把方向想清楚

Claude Code 在面对较复杂任务时会进入计划模式。计划模式的作用是先讨论需求、拆解步骤，再让用户决定是否批准执行。

当它给出计划后，通常会出现几类选择：

批准计划，并允许后续自动使用编辑工具。
批准计划，但后续编辑仍然需要手动确认。
暂停执行，继续和 Claude Code 讨论计划。

如果任务比较明确，可以批准计划并继续。如果任务还不清楚，建议先让它继续补充方案，比如页面风格、技术栈、目录结构、交互效果和验收标准。

计划模式的好处是减少返工。直接让 Agent 动手，可能很快生成一堆文件；但如果方向错了，后面越改越乱。

用 Shift + Tab 切换模式

在 Claude Code 中，可以用 Shift + Tab 在不同工作模式之间切换。常见用途是进入计划模式，或者切换到自动同意编辑工具的模式。

建议的习惯是：

新项目、新功能、大改动：先进入计划模式。
小改动、明确修复：可以直接执行。
涉及删除、批量替换、安装依赖：保持人工确认。

计划模式下，Claude Code 可能会主动询问项目细节。可以用方向键选择选项，用回车确认。提交反馈后，它会根据你的选择更新计划。

权限确认不要一律放开

Claude Code 执行命令、编辑文件或启动程序时，可能会申请权限。

常见选择包括：

只同意本次使用。
在当前会话中以后都同意同类命令。
拒绝或暂停。

如果只是启动本地页面、运行开发服务器、查看文件，可以根据需要允许。但不要为了省事长期使用“自动同意所有权限”的启动方式。

全自动权限适合非常确定、风险很低、项目已经有 Git 备份的场景。日常使用中，涉及删除文件、覆盖目录、安装依赖、联网、提交代码、执行脚本时，最好保留人工确认。

用终端模式执行本地命令

Claude Code 里可以进入终端命令模式，直接执行一些本地命令。

例如页面生成后，可以用系统命令打开 HTML 文件：

`1`	`start index.html`

这里的 start 是 Windows 下打开文件的命令，后面接文件名。这样可以快速查看生成页面，而不用手动去资源管理器里找文件。

终端模式适合执行这些轻量操作：

打开生成的页面。
查看目录内容。
启动本地开发服务器。
运行测试或构建命令。

但高风险命令仍然要谨慎，比如递归删除、移动目录、批量覆盖和修改系统环境。

回滚：结果不满意时及时退回

如果 Claude Code 做出的页面或代码不是你想要的，而且越改越乱，就应该及时回滚。

回滚功能可以把对话或代码退回到某个节点。常见选项包括：

同时回滚代码和对话。
只回滚对话。
只回滚代码。
把某个节点之前的内容压缩成摘要。
取消操作。

更推荐在明显走偏时选择“同时回滚代码和对话”。这样可以让上下文和文件状态一起回到较干净的位置。

需要注意：Claude Code 的回滚通常只能覆盖它通过内置工具创建或修改的文件。如果文件是通过外部命令生成的，未必能完整回滚。因此重要项目仍然要配合 Git 使用。

长提示词用编辑器写

复杂需求不要全挤在一行输入框里。

如果系统支持在文本编辑器中编辑长提示词，可以打开编辑器，把需求写完整后保存，再发送给 Claude Code。

长提示词里建议写清楚：

目标是什么。
使用什么技术栈。
不要做什么。
需要保留哪些文件。
完成后如何验证。
页面或功能的验收标准。

例如让 Claude Code 把一个普通 HTML 页面重构成更现代的技术栈时，不要只写“重构一下”。可以说明希望使用组件化结构、保留视觉内容、增加响应式布局，并要求它运行构建检查。

退出后用历史恢复会话

如果中途需要退出 Claude Code，可以正常退出。之后回到同一个项目目录，再次启动：

claude

如果发现前面的记录没有直接显示，可以使用历史相关命令查看最近会话，并加载之前的会话。

这个功能适合中断后继续工作。不过不要把会话历史当成唯一记忆。项目规则、技术栈、常用命令和注意事项，最好写进项目文件里。

用 CLAUDE.md 保存项目规则

CLAUDE.md 是 Claude Code 很重要的记忆文件。它通常放在项目根目录，用来告诉 Claude Code 项目规则、技术栈、目录结构和协作约束。

可以让 Claude Code 初始化这个文件：

/init

CLAUDE.md 适合记录：

项目目标。
技术栈。
常用启动、测试、构建命令。
目录说明。
代码风格。
不允许执行的操作。
提交和部署规则。

每次对话时，Claude Code 会把这类规则作为上下文的一部分使用。你可以把它理解成“项目说明书”。

一个简单验证方式是：在 CLAUDE.md 里加入一条明显规则，然后再向 Claude Code 提问。如果回答遵循了这条规则，就说明它确实读到了项目记忆。

用 @ 引用文件

在输入框中使用 @，可以选择文件或 Agent，把指定内容加入当前对话上下文。

这适合几类场景：

让 Claude Code 阅读某个配置文件。
让它修改某个指定页面。
让它根据 CLAUDE.md 或其他文档继续工作。
明确告诉它“只看这个文件，不要猜项目结构”。

相比把文件内容复制到输入框里，@ 引用更清晰，也更不容易漏内容。

查看和压缩上下文

长时间对话后，上下文会越来越大。上下文太长时，模型可能变慢，也可能开始忽略早期细节。

可以使用上下文查看命令了解当前占用情况：

`1`	`/context`

如果上下文已经很长，可以压缩历史：

`1`	`/compact`

如果压缩后效果仍然不好，可以考虑清空当前上下文：

/clear

清空上下文后，Claude Code 仍然可以通过项目文件、CLAUDE.md 和当前目录重新理解一部分项目情况，但不会保留完整对话历史。

实用建议是：一个任务完成后就开新会话；项目级规则写进 CLAUDE.md；临时讨论不要无限堆在一个聊天里。

Skills：把固定流程做成说明书

Skills 可以理解为 Claude Code 的工作说明书。它不是一次性提示词，而是一套可复用的任务流程。

例如你经常要生成周报，就可以创建一个周报 Skill，里面写清楚：

输入需要哪些信息。
输出格式是什么。
语气和结构怎么控制。
哪些内容必须保留。
哪些内容不能编造。

Skills 通常由 name、description 和具体指令组成。安装到全局 Skills 目录后，Claude Code 在遇到相关任务时可以识别并加载。

这适合处理重复工作：

周报。
代码审查模板。
文档整理。
图片批处理。
固定格式文章。
项目初始化流程。

如果你发现自己反复复制同一段提示词，就可以考虑把它做成 Skill。

Agents：把子任务交给独立助手

Agents 和 Skills 不一样。

Skill 更像说明书，告诉 Claude Code 怎么做某类任务；Agent 更像一个独立助手，可以在当前主会话之外执行任务，完成后把结果返回。

Agents 的价值在于隔离上下文。比如做代码巡检时，可以创建一个只读 Agent，让它只读取项目并输出报告，不直接修改文件。这样不会污染主会话，也能降低误操作风险。

创建 Agent 时通常要考虑：

是项目级 Agent，还是用户级 Agent。
是否需要 Claude Code 帮你生成配置。
允许哪些工具权限。
使用哪个模型。
是否保存记忆。
Agent 的提示词是否足够明确。

对于代码巡检类 Agent，建议只给读取权限，不给写入权限。先让它输出报告，再由主会话决定是否修改代码。

插件：打包 Skills、Agents、MCP 和 Hooks

插件可以理解为更完整的能力包。它可能同时包含：

Skills
Agents
MCP
Hooks

相比单独安装一个 Skill，插件更适合成套能力。例如前端设计插件可能会把页面审美、布局规则、组件习惯和相关 Agent 一起打包。

安装插件时通常会有几个位置选项：

如果是个人常用能力，可以放在用户目录；如果是团队项目约定，可以放进项目目录；如果只是临时测试，放本地项目目录更稳。

插件能明显改善特定任务效果

在前端页面生成这类任务里，插件往往比裸提示词更稳定。

例如同样是“制作一个摄影师个人网页”，只用普通提示词可能生成一个能看的页面；如果明确使用前端设计插件，页面结构、视觉层次、间距、配色和整体完成度通常会更好。

这并不意味着插件能替代人工审美。更合理的用法是：先让插件生成一个更好的初稿，再由人做细节微调。

一套更稳的 Claude Code 工作流

把上面这些技巧组合起来，可以形成一套比较稳的流程：

在项目目录启动 claude。
先用计划模式讨论需求。
批准计划前确认技术栈和验收标准。
涉及高风险操作时保留手动确认。
用终端模式执行本地预览和测试。
结果走偏时及时回滚。
把项目规则写进 CLAUDE.md。
长对话定期查看和压缩上下文。
重复流程沉淀成 Skills。
巡检、研究、分析类任务交给只读 Agents。
特定领域任务优先用插件。
重要项目始终配合 Git 提交点。

这样使用 Claude Code，会比单纯“发一句需求等它生成”稳定得多。

小结

Claude Code 的效率不只来自模型能力，也来自工作流控制。

计划模式决定方向，权限确认控制风险，回滚减少返工，CLAUDE.md 保存项目规则，/context、/compact 和 /clear 管理上下文，Skills 复用固定流程，Agents 隔离复杂子任务，插件则把成套能力打包进项目。

真正好用的 Claude Code 工作方式，是让它在清楚边界内持续推进任务，而不是把整个项目一次性交给它自由发挥。

opencode、Claude Code、Codex 有什么区别？开源 AI 编程工具使用指南

Fri, 08 May 2026 08:33:37 +0800

opencode 是 anomalyco 开源的 AI Coding Agent。它的定位很直接：让开发者在终端里使用一个可编程、可扩展、可接入多家模型的代码助手。

如果把它和 Claude Code、Codex 放在一起看，三者解决的是同一类问题：让 AI 进入真实代码库，理解上下文，修改文件，运行命令和测试。但它们的产品取向不一样。

opencode 更强调开源、多模型和终端 TUI；Claude Code 更强调 Anthropic 模型生态和本地工程协作；Codex 则是 OpenAI 的 AI coding agent，可以在终端、IDE、Codex app 和云端任务里使用。

opencode 适合谁

opencode 更适合这几类开发者：

想在终端里完成代码修改、项目分析和工程任务的人。
希望 AI Coding Agent 不绑定单一模型提供商的人。
偏好开源工具，想自己审计、扩展或二次开发的人。
已经习惯 Neovim、TUI、命令行工作流的人。
希望以后用桌面端、移动端或其他客户端远程驱动同一个编码代理的人。

它的重点不是做一个聊天窗口，而是把 AI 编程能力放进开发者原本使用的终端和项目目录里。

安装方式

官方 README 提供了多种安装方式。

# 直接安装
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS 和 Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# 其他方式
mise use -g opencode
nix run nixpkgs#opencode

官方也提醒，安装前最好先移除 0.1.x 之前的旧版本，避免旧版本残留造成问题。

安装脚本会按优先级选择安装目录：

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

如果需要指定路径，可以这样写：

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

桌面应用还在 Beta

除了命令行工具，opencode 也提供桌面应用，目前仍处于 Beta。可以从 GitHub Releases 或 opencode.ai/download 下载。

桌面端覆盖这些平台：

平台	文件
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`、`.rpm` 或 `.AppImage`

macOS 和 Windows 也可以通过包管理器安装桌面端。

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

两种内置 Agent 模式

opencode 内置两种 Agent，可以通过 Tab 键切换。

build 是默认模式，拥有完整开发权限，适合直接修改代码、运行命令和推进工程任务。

plan 是只读模式，更适合分析陌生代码库、理解项目结构、制定修改方案。它默认拒绝文件编辑，并且在运行 bash 命令前会询问。

另外，opencode 还带有一个 general 子 Agent，用于复杂搜索和多步骤任务。用户可以在消息中输入 @general 调用。

这个设计比较实用：真正动手前先用 plan 看清楚项目，需要改代码时再切到 build。对于大型仓库，读写权限分开能减少误操作。

Codex 是什么

Codex 是 OpenAI 的 AI coding agent，用来帮助开发者写代码、审查代码、修复 bug 和交付工程任务。

和单纯的代码补全工具不同，Codex 更接近一个可以操作代码库的 Agent。它可以在本地工具里和你结对，也可以把任务委托到云端执行。OpenAI 官方资料里提到，Codex 可以通过 CLI、IDE、Codex app、ChatGPT/Codex 云端等不同入口使用。

对开发者来说，Codex 的重点有几处：

可以读取代码库、编辑文件、运行命令和测试。
支持终端、IDE、应用和云端等多种使用界面。
适合修 bug、写功能、重构、迁移、代码审查和测试补齐。
更偏 OpenAI 账户、模型和 Codex 产品体系。
云端任务适合并行处理多个相对清晰的工程任务。

如果 opencode 更像一个开放的终端代理框架，Codex 更像 OpenAI 提供的一整套 AI 编程工作台：本地可以结对，云端可以委托，团队可以把它接入更长的工程流程。

三者核心区别

opencode、Claude Code、Codex 都是 AI 编程工具，但选择时可以先看这几个维度。

工具	核心定位	主要优势	更适合
`opencode`	开源 AI Coding Agent	开源、多模型、TUI、客户端/服务器架构	想要开放工具链、可替换模型、偏终端工作流的开发者
`Claude Code`	Anthropic 的命令行编程工具	Claude 模型体验、代码理解、长上下文、工程任务协作	已经使用 Claude/Anthropic 生态，希望本地推进代码任务的开发者
`Codex`	OpenAI 的 AI coding agent	CLI、IDE、Codex app、云端任务、多 Agent 工作流	已经使用 ChatGPT/OpenAI，希望本地结对和云端委托并用的团队

简单说，opencode 的关键词是“开源和可替换”，Claude Code 的关键词是“Claude 生态和本地工程代理”，Codex 的关键词是“OpenAI 生态和多入口协作”。

和 Claude Code 的区别

opencode 的官方 FAQ 直接把 Claude Code 拿来对比。两者能力上很接近，但差异主要在这几处。

第一，opencode 是 100% 开源项目，代码托管在 GitHub，并使用 MIT license。

第二，opencode 不绑定单一模型提供商。它推荐 OpenCode Zen 提供的模型，但也可以搭配 Claude、OpenAI、Google 或本地模型。对开发者来说，这意味着模型成本、能力和可用性变化时，不必被某一个平台锁住。

第三，opencode 内置可选的 LSP 支持。对代码补全、跳转、诊断和项目理解来说，LSP 是非常关键的基础能力。

第四，opencode 更强调 TUI。它由 Neovim 用户和 terminal.shop 的创建者打造，产品重心明显放在终端体验上。

第五，opencode 采用客户端/服务器架构。也就是说，opencode 可以在你的电脑上运行，未来由 TUI、桌面端、移动端或其他客户端来控制。TUI 只是其中一种前端形态。

什么时候选 opencode、Claude Code 或 Codex

如果你已经在使用 Claude Code 或 Codex，opencode 不一定是立刻替换它们的工具。更合理的看法是：它提供了一个开源、可替换模型、偏终端的选择。

可以优先考虑 opencode 的场景包括：

你希望 AI 编程工具尽量开源。
你不想把工作流绑定在某个模型供应商上。
你希望用同一个工具测试 Claude、OpenAI、Google 或本地模型。
你喜欢 TUI，不希望主要工作流被桌面应用或网页应用打断。
你关注客户端/服务器架构带来的远程控制能力。

可以优先考虑 Claude Code 的场景包括：

你主要使用 Claude 模型。
你重视长上下文、代码理解和复杂工程任务协作。
你希望在本地仓库中持续推进修改、测试和重构。
你更信任 Anthropic 对 Claude Code 的默认产品体验。

可以优先考虑 Codex 的场景包括：

你已经在使用 ChatGPT 或 OpenAI 账户体系。
你希望同一个 coding agent 覆盖终端、IDE、桌面应用和云端任务。
你想把较清晰的 bug 修复、功能开发、迁移、测试补齐交给云端并行处理。
你需要代码审查、后台任务、团队协作和多 Agent 工作流。

如果你更看重官方闭环体验、模型默认配置、企业管理和现成集成，Claude Code 或 Codex 可能更省心；如果你更看重可控性、开放性和 provider-agnostic，opencode 更值得关注。

需要注意的地方

opencode、Claude Code 和 Codex 都发展很快，GitHub release、安装命令、桌面端文件名、模型可用性和套餐权限都可能变化。实际安装和选型前，最好直接查看各自官方 README、文档和发布页面。

另外，它的桌面应用仍然标注为 Beta，不适合默认当作稳定生产工具。对于日常工程任务，终端版仍然是更主要的入口。

从工具趋势看，opencode 代表的是 AI Coding Agent 的开放工具链方向：模型可以替换，客户端可以替换，核心代理能力尽量开放。Codex 和 Claude Code 则更像模型公司把 coding agent 做成完整产品入口。对开发者来说，这两条路线会长期并存。

参考链接

opencode GitHub：https://github.com/anomalyco/opencode
opencode 官网：https://opencode.ai
opencode 文档：https://opencode.ai/docs
opencode Releases：https://github.com/anomalyco/opencode/releases
OpenAI Codex：https://openai.com/codex/
Using Codex with your ChatGPT plan：https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started：https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Warp 开源：从终端到 Agentic Development Environment

Thu, 07 May 2026 20:15:08 +0800

warpdotdev/warp 是 Warp 的开源客户端仓库。Warp 官方现在把它定位为一个“从终端生长出来的 agentic development environment”，也就是以终端为基础，但把 AI coding agent、代码库索引、任务管理和开发工作流放进同一个环境里。

这不是一个普通的终端模拟器开源仓库。它更像是在回答一个问题：当 Claude Code、Codex、Gemini CLI 这类 agent 越来越常见时，终端本身要不要变成一个能调度、观察和管理 agent 的开发环境？

Warp 的答案是：要。

这个仓库现在是什么状态

截至 2026 年 5 月 7 日查看，warpdotdev/warp 是公开仓库，GitHub 页面显示约 56k stars、4.1k forks。仓库 README 说明，Warp 的客户端代码已经开源，并欢迎社区贡献。

仓库的主语言是 Rust。GitHub 语言统计里，Rust 占比超过 98%。这和 Warp 的定位一致：它不是网页壳，而是一个跨平台的原生开发工具。

README 中有几个信息点很重要：

Warp 是一个 agentic development environment, born out of the terminal。
它可以使用内置 coding agent，也可以接入 Claude Code、Codex、Gemini CLI 等外部 CLI agent。
OpenAI 是新开源 Warp 仓库的 founding sponsor。
仓库中的 agentic management workflows 由 GPT models 驱动。
Warp UI 框架相关 crate 使用 MIT license，其余代码使用 AGPL v3。

这些信息说明，Warp 开源不是单纯把一个终端放出来，而是把它作为“agent 工作流实验场”来运营。

Warp 不只是终端

传统终端主要解决三个问题：

启动 shell。
执行命令。
显示输出。

Warp 早期的差异化，是让终端更现代：命令块、补全、历史、协作、UI 化交互、跨平台体验。现在它的重心继续往前走，开始围绕 AI agent 组织开发流程。

从 README 看，Warp 不再只强调“更好用的 terminal”，而是强调：

内置 coding agent。
支持外部 CLI agent。
issue triage。
spec 编写。
PR review。
contributor coordination。
可观察的 agent sessions。

也就是说，Warp 想把终端从“你输入命令的地方”，变成“你和多个 agent 一起工作的地方”。

Oz 和开源项目管理

README 里多次提到 Oz。

Warp 的贡献概览页面可以看到成千上万个 Oz agents 在做 issue triage、写 specs、实现改动、review PR。这个设计很有意思，因为它把 AI agent 从“帮个人写代码”扩展到了“帮开源项目管理协作”。

传统开源项目最难的不是写代码，而是维护：

issue 太多，没人分类。
bug 和 feature request 混在一起。
新贡献者不知道哪些任务能做。
PR review 压力大。
维护者很难持续跟进社区讨论。

Warp 的思路是，让 agent 先承担一部分项目管理和协作工作。README 中还提到 Oz for OSS，这是面向维护者的合作计划，用于把类似 agentic open-source management workflows 带到其他开源仓库。

这说明 Warp 的野心不只是终端产品本身，也包括探索 AI 时代开源维护的新模式。

仓库结构和技术栈

从仓库结构看，Warp 是一个大型 Rust 项目。

根目录里能看到：

app/：主应用相关代码。
crates/：核心 Rust crates。
assets/：资源文件。
command-signatures-v2/：命令签名相关内容。
docker/、script/、resources/、specs/ 等工程目录。
.claude/、.warp/、.agents/skills 等 agent 相关配置。

WARP.md 里给出了更详细的工程说明。它提到 Warp 是 Rust-based terminal emulator，并使用一个自研 UI 框架 WarpUI。

主要模块可以粗略理解为：

app/：终端模拟、shell 管理、AI 集成、Drive、认证、设置、workspace 和 session。
crates/warp_core/：核心工具和平台抽象。
crates/editor/：文本编辑功能。
crates/warpui/ 和 crates/warpui_core/：自研 UI 框架。
crates/ipc/：进程间通信。
crates/graphql/：GraphQL 客户端和 schema。

WARP.md 还提到几个架构特点：

Entity-Handle system。
模块化 workspace 结构。
macOS、Windows、Linux 跨平台，以及 WASM target。
AI integration，包含 Agent Mode、上下文感知和代码库索引。
Warp Drive 云同步。

这说明 Warp 的复杂度已经接近一个完整 IDE，而不是传统意义上的轻量 terminal。

本地构建方式

README 给出的本地构建方式很简洁：

1
2
3

./script/bootstrap
./script/run
./script/presubmit

其中：

./script/bootstrap：执行平台相关初始化。
./script/run：构建并运行 Warp。
./script/presubmit：执行格式化、clippy 和测试等提交前检查。

WARP.md 里还列出了更细的命令：

cargo run
cargo bundle --bin warp
cargo nextest run --no-fail-fast --workspace --exclude command-signatures-v2
cargo fmt
cargo clippy --workspace --all-targets --all-features --tests -- -D warnings

如果要给 Warp 提交代码，./script/presubmit 基本是必须跑的。

贡献流程

Warp 的贡献流程不是简单“发 PR 就行”。

README 描述了一个从 issue 到 PR 的轻量流程：

先搜索已有 issue。
没有重复再提交 bug 或 feature request。
维护者会 review issue，并可能打上 readiness label。
ready-to-spec 表示设计可以被贡献者展开成 spec。
ready-to-implement 表示设计已相对明确，可以开始写代码 PR。
贡献者可以认领带标签的 issue。

这个流程适合大型开源项目。它把“想法”“设计”“实现”拆开，减少贡献者一上来就写错方向的风险。

对 AI agent 来说，这也很适合。agent 可以先整理 issue、写 spec、补测试，再进入实现。Warp 自己也在用这种方式展示 agentic project management。

许可：MIT + AGPL v3

Warp 采用双许可结构。

README 说明：

Warp UI framework，也就是 warpui_core 和 warpui crates，使用 MIT license。
仓库其余代码使用 AGPL v3。

这点很重要。AGPL v3 对网络服务和分发有更强的开源要求。如果你只是学习、研究、贡献代码，问题不大；但如果想把 Warp 代码用于商业产品或闭源衍生项目，就必须认真读 license，必要时咨询法律意见。

简单说，Warp 是开源了，但不是“随便拿去闭源商用”的宽松许可。

值得关注的地方

第一，Warp 把终端、agent、项目管理放在一起。

很多 AI coding 工具仍然是 CLI 或编辑器插件。Warp 试图从终端入口出发，把 agent 任务、代码执行、命令输出、PR 工作流和团队协作整合起来。

第二，Warp 的开源方式很适合观察 agent 工作流。

它不只是发布代码，还把贡献概览、agent session、issue triage 和 spec 流程公开出来。对于想研究 AI 如何参与开源协作的人，这个仓库本身就是样本。

第三，Warp 是一个复杂 Rust 桌面应用。

如果你想学习 Rust GUI、终端模拟器、跨平台应用、GraphQL 客户端、云同步和 AI 集成，Warp 仓库有不少可看的结构。但它不是小项目，新贡献者需要先读文档和 issue 流程。

第四，Warp 支持“自带 agent”和“bring your own CLI agent”两条线。

这点很现实。开发者不会只用一个 agent。Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 等工具会长期共存。Warp 如果能成为它们的工作台，就比单一终端更有价值。

适合谁关注

如果你是普通终端用户，关注 Warp 的意义在于：终端可能正在从命令行工具变成 AI 工作台。

如果你是 AI coding agent 重度用户，Warp 值得关注，因为它试图管理多个 agent，而不是只做一个聊天入口。

如果你是开源维护者，可以关注 Oz for OSS 这条线。它试图用 agent 做 issue triage、PR review、社区协作和贡献者引导。

如果你是 Rust 开发者，Warp 是一个大型真实桌面应用样本，可以研究它如何组织 UI、终端、云同步、AI 集成和跨平台代码。

如果你只是想找一个能马上替代传统终端的工具，建议先下载正式版使用，再决定是否研究源码。直接从源码构建更适合贡献者和深度玩家。

简短判断

Warp 开源的重点，不只是“一个现代终端开源了”。

更准确地说，Warp 正在把终端升级成 agentic development environment：终端负责连接 shell、代码库、命令执行、agent、issue、PR 和协作流程。

在 AI coding agent 继续增长的背景下，开发环境的入口可能会发生变化。过去是 IDE 统治开发体验，终端负责命令执行；现在终端可能反过来成为 agent 协作的中心。Warp 这个仓库，正是在探索这种可能性。

Hermes + Qwen3.6：本地 Agent 的一套低成本部署方案

Mon, 04 May 2026 06:40:30 +0800

用 llama.cpp 在 WSL2 中运行 Qwen3.6 GGUF 模型，再把 Hermes Agent 接到本地 OpenAI-compatible API。这样可以在自己的电脑上获得一个可长期在线的本地 AI 助手，不再按在线服务的 Token 额度计费。

这套方案适合想体验本地 AI Agent、又希望保留数据隐私和长期可控性的用户。它可以用于日常问答、写作、代码辅助、资料整理和简单自动化任务。需要注意的是，模型规模越大，对显存要求越高；原文示例使用的是 Qwen3.6-27B，显存 24GB 更稳。如果显存较小，应选择更小尺寸或更低量化的模型。

方案结构

整体链路很简单：

Windows 上安装 WSL2 和 Ubuntu 24.04。
在 WSL2 中安装 CUDA Toolkit、编译 llama.cpp。
下载 Qwen3.6 GGUF 模型。
用 llama-server 启动本地模型服务。
安装 Hermes Agent，并把它配置到 http://localhost:8080/v1。
可选：写启动脚本，让 WSL2 打开时自动启动模型服务。

Hermes 负责 Agent 能力，Qwen3.6 负责本地大模型能力。两者组合后，可以把电脑变成一个本地私有 AI 助理。

安装 WSL2 和 Ubuntu

在 Windows PowerShell 管理员窗口中执行：

1
2

wsl --install
wsl --set-default-version 2

重启后安装 Ubuntu 24.04：

`1`	`wsl --install -d Ubuntu-24.04`

安装完成后，Ubuntu 会提示设置用户名和密码。进入 Ubuntu 后，先检查 NVIDIA GPU 是否能在 WSL2 中正常识别：

`1`	`nvidia-smi`

如果无法识别 GPU，通常需要先更新 Windows 端的 NVIDIA 显卡驱动。WSL2 会继承 Windows 驱动，但 CUDA Toolkit 仍需要在 WSL2 内单独安装。

安装 Python 和基础工具

`1`	`sudo apt update && sudo apt install -y python3-pip python3-venv`

后续还需要编译工具、Git 和 CMake：

`1`	`sudo apt install -y cmake build-essential git`

编译 llama.cpp

先拉取源码：

1
2

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp

如果 WSL2 中已经有可用 CUDA 环境，可以直接编译：

1
2

cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

CMAKE_CUDA_ARCHITECTURES=89 适合 Ada 架构显卡，例如 RTX 40 系列。其他显卡应按实际架构调整。

如果编译时报 CUDA Toolkit 缺失，先在 WSL2 中安装 CUDA Toolkit：

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update
sudo apt install -y cuda-toolkit-12-8

安装完成后配置环境变量：

export PATH=/usr/local/cuda-12.8/bin:$PATH
export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH
echo 'export PATH=/usr/local/cuda-12.8/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.8/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc

然后重新编译：

cd ~/llama.cpp
rm -rf build
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=89
cmake --build build -j$(nproc)

下载 Qwen3.6 GGUF 模型

原文示例使用 unsloth/Qwen3.6-27B-GGUF 中的 Qwen3.6-27B-UD-Q4_K_XL.gguf：

1
2
3

hf download unsloth/Qwen3.6-27B-GGUF \
Qwen3.6-27B-UD-Q4_K_XL.gguf \
--local-dir ~/models/

这个文件约 17GB。如果 Hugging Face 下载慢，可以换 ModelScope 等国内镜像。显存不足时不要硬上 27B，可以换更小模型或更低量化版本。

启动本地模型服务

根据自己的模型文件名启动 llama-server：

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080

启动成功后，在 Windows 浏览器访问：

`1`	`http://localhost:8080`

如果要让 Hermes Agent 或其他 OpenAI-compatible 客户端调用，API 地址通常是：

`1`	`http://localhost:8080/v1`

Thinking 模式取舍

Qwen3.6 默认可能启用 Thinking 模式。它适合复杂推理、复杂代码问题、多步骤分析，但速度会慢一些。

如果想关闭 Thinking 模式，可以停止服务后增加 --chat-template-kwargs 参数：

~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 32768 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--chat-template-kwargs '{"enable_thinking":false}' \
--port 8080

关闭 Thinking 后，简单问答、写作、代码补全和解释代码会更快；但复杂算法设计、疑难 Debug 和架构分析仍建议开启 Thinking。

安装 Hermes Agent

保持 llama-server 运行，再新开一个 WSL2 终端安装 Hermes Agent：

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

安装脚本会处理 Python、Node.js、ripgrep、ffmpeg 等依赖。配置模型端点时选择自定义 endpoint：

1
2
3

URL: http://localhost:8080/v1
API Key: 12345678
Model: 自动识别

API Key 对本地 llama-server 来说可以随便填一个占位值。配置完成后，可以继续接 Telegram、微信、QQ、Discord 等聊天工具，让 Hermes Agent 通过这些入口调用本地模型并执行任务。

自动启动模型服务

可以写一个启动脚本，让 WSL2 终端打开时自动启动模型服务。

创建脚本：

cat > ~/start-llm.sh << 'EOF'
#!/bin/bash
echo "Starting Qwen3.6-27B llama-server..."
~/llama.cpp/build/bin/llama-server \
--model ~/models/Qwen3.6-27B-UD-Q4_K_XL.gguf \
--n-gpu-layers 99 \
--ctx-size 65536 \
--flash-attn on \
--temp 1.0 \
--top-p 0.95 \
--top-k 20 \
--presence-penalty 1.5 \
--port 8080 \
--host 0.0.0.0 &
echo "llama-server started, PID: $!"
echo "API: http://localhost:8080/v1"
echo "Chat UI: http://localhost:8080"
EOF
chmod +x ~/start-llm.sh

写入 .bashrc：

echo '# Auto-start llama-server' >> ~/.bashrc
echo 'if ! pgrep -f "llama-server" > /dev/null 2>&1; then' >> ~/.bashrc
echo '    ~/start-llm.sh' >> ~/.bashrc
echo 'fi' >> ~/.bashrc

这样每次打开 WSL2 终端时，如果 llama-server 没有运行，就会自动启动；如果已经在运行，就会跳过，避免重复启动。

注意事项

27B 模型对显存要求较高，24GB 显存体验更稳；显存较小时应换小模型。
--ctx-size 65536 会显著增加显存和内存压力，不稳定时先降到 32768 或更低。
WSL2 中 CUDA Toolkit 和 Windows 显卡驱动都要正常，缺一边都可能导致 CUDA 编译或运行失败。
Hermes Agent 接本地服务时，本质上是调用 OpenAI-compatible API，关键是 http://localhost:8080/v1 能正常响应。
如果要从手机或其他设备访问，需要额外处理 Windows 防火墙、局域网地址和安全隔离，不要把本地模型服务直接暴露到公网。

如何在 Cline 中调用 DeepSeek V4 Pro

Fri, 01 May 2026 20:59:06 +0800

Cline 本身已经支持 OpenAI Compatible Provider。 DeepSeek API 也兼容 OpenAI SDK 风格的调用方式，所以把 deepseek-v4-pro 接到 Cline 里并不复杂：选 OpenAI Compatible，填 DeepSeek 的 Base URL、API Key 和模型名即可。

下面按 VS Code 插件界面和 Cline CLI 两种方式整理。

准备 DeepSeek API Key

先到 DeepSeek 开放平台创建 API Key。

需要准备三个值：

项目	填写内容
Provider	`OpenAI Compatible`
Base URL	`https://api.deepseek.com`
Model ID	`deepseek-v4-pro`

DeepSeek 官方文档说明，V4 系列使用现有 OpenAI 兼容接口，base_url 保持为 https://api.deepseek.com，调用时把 model 设置为 deepseek-v4-pro 或 deepseek-v4-flash。

在 Cline 插件里配置

如果你用的是 VS Code 里的 Cline 插件，可以按这个路径配置：

打开 VS Code 侧边栏里的 Cline。
进入 Cline 的设置或模型配置页面。
Provider 选择 OpenAI Compatible。
API Key 填入 DeepSeek API Key。
Base URL 填：

`1`	`https://api.deepseek.com`

Model ID 填：

`1`	`deepseek-v4-pro`

保存配置，回到 Cline 对话框测试一次简单任务。

可以先让 Cline 做一个低风险测试：

`1`	`请读取当前项目目录结构，并总结这个项目是什么类型，不要修改任何文件。`

如果能正常读取和回答，说明模型链路已经通了。

在 Cline CLI 中配置

如果你使用 Cline CLI，可以用 cline provider configure openai-compatible 进入交互式配置。

示例：

`1`	`cline provider configure openai-compatible`

交互时填写：

1
2
3

API Key: sk-...
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

配置完成后，可以用一个只读任务测试：

`1`	`cline "Summarize this repository structure without changing files."`

如果你希望先降低成本，也可以把 Model ID 临时改成：

`1`	`deepseek-v4-flash`

等遇到复杂规划、事实核查、多工具协作或高风险代码修改时，再切回 deepseek-v4-pro。

上下文长度怎么填

DeepSeek V4 Pro 和 Flash 都支持很长上下文。在 Cline 里如果需要手动填写 context window，可以按 DeepSeek 官方模型页给出的 1M 上下文来理解。

实际使用时不建议一开始就把所有文件都塞进上下文。 Cline 会按任务读取文件，通常更好的方式是：

先让它看目录结构；
再让它定位相关文件；
最后只围绕目标文件执行修改。

这样更省 Token，也更容易保持任务边界清晰。

常见问题

1. 提示模型不存在

先检查 Model ID 是否写成：

`1`	`deepseek-v4-pro`

不要写成 DeepSeek V4 Pro、deepseek-v4 或其他显示名称。

2. 提示 401 或认证失败

检查 API Key：

是否复制完整；
是否带了多余空格；
是否填到了 Cline 当前正在使用的 provider 配置里；
DeepSeek 账户是否有可用额度。

3. 提示连接失败

检查 Base URL：

`1`	`https://api.deepseek.com`

不要在末尾额外拼 /v1/chat/completions。 Cline 的 OpenAI Compatible Provider 会自己按兼容接口组织请求。

4. Cline 调用很贵怎么办

可以先把日常任务切到 deepseek-v4-flash，只在复杂任务里使用 deepseek-v4-pro。

另外，尽量把任务描述写清楚：

`1`	`只修改登录页相关文件，不要重构无关模块。先给出计划，确认后再改代码。`

Agent 任务最怕边界不清。边界越清楚，读文件越少，工具调用越少，成本也越可控。

5. 报错 reasoning_content must be passed back

如果你看到类似错误：

{
  "message": "400 The `reasoning_content` in the thinking mode must be passed back to the API.",
  "code": "invalid_request_error",
  "modelId": "deepseek-v4-pro"
}

这通常不是 Key、额度或 Base URL 的问题，而是 DeepSeek V4 Pro 的 thinking mode 和当前客户端的多轮工具调用记录没有对齐。

DeepSeek 官方文档说明：

thinking mode 默认是 enabled；
thinking mode 下会返回 reasoning_content；
如果某一轮发生了 tool call，后续请求必须把该轮 assistant message 里的 reasoning_content 一起传回 API；
如果客户端没有正确回传，就会返回 400。

Cline 通过 OpenAI Compatible Provider 接入时，如果当前版本没有完整保留并回传 DeepSeek 的 reasoning_content，就可能在第二轮或工具调用后触发这个错误。

可尝试的处理顺序：

先升级 Cline 到最新版；
确认使用的是 OpenAI Compatible，而不是普通 OpenAI provider；
如果 Cline 支持自定义 request body，尝试关闭 thinking mode：

{
  "thinking": {
    "type": "disabled"
  }
}

如果 Cline 不支持额外 body 参数，暂时改用不触发该问题的模型或服务中转；
等 Cline 适配 DeepSeek V4 的 reasoning_content 回传后，再切回 deepseek-v4-pro。

需要注意：关闭 thinking mode 会牺牲一部分复杂推理能力，但可以绕开客户端没有回传 reasoning_content 的兼容性问题。

一个可直接复制的配置清单

Provider: OpenAI Compatible
API Key: sk-你的 DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

如果要低成本模式：

Provider: OpenAI Compatible
API Key: sk-你的 DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-flash

小结

在 Cline 中调用 DeepSeek V4 Pro 的关键只有三步：

Provider 选择 OpenAI Compatible；
Base URL 填 https://api.deepseek.com；
Model ID 填 deepseek-v4-pro。

配置完成后，建议先用只读任务测试，再逐步交给它执行真实代码修改。如果你经常跑 Agent 任务，可以把 Flash 和 Pro 分开用：Flash 负责高频轻量任务，Pro 负责复杂判断和兜底。

参考来源：

DeepSeek V4 降价如何改写 AI Agent 的成本模型

Fri, 01 May 2026 19:47:47 +0800

DeepSeek V4 发布时没有制造出特别夸张的声量。没有大型发布会，也没有一眼碾压所有对手的跑分叙事。但几天之后，它真正影响行业的地方开始显现：连续降价。

这次变化的重点不是“模型强了一点”，而是“使用成本被打到另一个层级”。当 Token 价格低到普通 Agent 任务几毛钱、一两块钱就能跑完时，很多 Coding Plan、Token Plan 的商业逻辑都会被重新审视。

发布当天没有炸场

DeepSeek V4 的第一波反馈并不算热烈。很多人期待它像 R1 那样带来强烈冲击：跑分全面领先、国产算力验证、多模态和 Agent 能力一起爆发。但真正发布后，大家发现它更像一次稳健升级。

V4 Pro 确实是强模型，尤其在代码、数学、长上下文和 agentic coding 上表现不错。但它不是那种让所有同类模型瞬间失色的产品。所以发布当天，舆论一度有些尴尬：想夸，但很难找到一个足够爆炸的角度。

真正的转折点不是发布当天，而是后续价格调整。

连续降价才是关键

DeepSeek V4 发布后，价格开始连续下探。按照 DeepSeek 官方价格页和原文整理的信息，当时的大致价格是：

DeepSeek V4 Flash：输入 100 万 Token 约 1 元；缓存命中后 100 万 Token 约 2 分钱；
DeepSeek V4 Pro：输入 100 万 Token 约 3 元；缓存命中后 100 万 Token 约 2.5 分；
全系列模型输入缓存命中价格降到首发价格的 1/10；
V4 Pro 曾处在 2.5 折优惠期，优惠延长到 2026 年 5 月 31 日 23:59。

如果按美元 API 价格看，会更直观：

模型	缓存命中输入	非缓存输入	输出	上下文
`deepseek-v4-flash`	$0.0028 / 100万 Token	$0.14 / 100万 Token	$0.28 / 100万 Token	1M
`deepseek-v4-pro` 促销价	$0.003625 / 100万 Token	$0.435 / 100万 Token	$0.87 / 100万 Token	1M
`deepseek-v4-pro` 原价	$0.0145 / 100万 Token	$1.74 / 100万 Token	$3.48 / 100万 Token	1M

这里要注意两个点。

第一，V4 Pro 的 $0.435 / $0.87 是促销价，不是长期原价。 DeepSeek 官方说明里，这个 75% 折扣延长到 2026 年 5 月 31 日 15:59 UTC。

第二，缓存命中价格才是 Agent 成本模型里的关键。 Flash 的缓存命中输入低到 $0.0028 / 100万 Token，Pro 促销期缓存命中输入是 $0.003625 / 100万 Token。这意味着大量重复项目上下文、工具定义、系统提示词和历史摘要，不再按完整输入价格计费。

这个价格最重要的地方，是它让很多任务的 Token 成本变得“不敏感”。过去开发者会担心一次 Agent 任务吃掉大量上下文、反复读写代码、频繁调用工具。现在只要缓存命中率足够高，成本会被压得很低。

和 GPT、Claude 的价格对比

只看 DeepSeek 自己的价格，还不容易感受到差距。把它和同期常见的闭源模型放在一起，对比会更明显。

模型	输入	缓存输入	输出	适合场景
`deepseek-v4-flash`	$0.14 / M	$0.0028 / M	$0.28 / M	高频 Agent、常规 coding、批量任务
`deepseek-v4-pro` 促销价	$0.435 / M	$0.003625 / M	$0.87 / M	复杂 coding、规划、事实核查
`deepseek-v4-pro` 原价	$1.74 / M	$0.0145 / M	$3.48 / M	促销结束后的 Pro 成本基准
GPT-5.5	$5 / M	$0.50 / M	$30 / M	高质量复杂任务、通用推理
GPT-5.4	$2.50 / M	$0.25 / M	$15 / M	编程和专业任务的中档选择
GPT-5.4 mini	$0.75 / M	$0.075 / M	$4.50 / M	成本更低的通用/子任务模型
Claude Opus 4.7	$5 / M	$0.50 / M	$25 / M	高质量写作、复杂推理、长任务
Claude Sonnet 4.6	$3 / M	$0.30 / M	$15 / M	编程、Agent、综合任务
Claude Haiku 4.5	$1 / M	$0.10 / M	$5 / M	轻量任务、摘要、分类

这张表里最刺眼的是输出价格。 Agent 不只读上下文，还会不断生成计划、补丁、解释、日志和下一步动作。如果输出很多，DeepSeek V4 Pro 促销价的 $0.87 / M 和 GPT-5.5 的 $30 / M、Claude Sonnet 4.6 的 $15 / M 相比，差距会被不断放大。

即使按 V4 Pro 原价 $3.48 / M 输出算，它也明显低于 GPT-5.4、GPT-5.5 和 Claude Sonnet / Opus。如果任务可以用 Flash 承担，输出价会进一步降到 $0.28 / M。

缓存输入差距更夸张。 DeepSeek V4 Flash 的缓存输入是 $0.0028 / M，而 GPT-5.5 和 Claude Opus 4.7 的缓存输入都是 $0.50 / M。这不是同一个数量级。对反复读取同一代码仓库的 Agent 来说，这个差距比普通聊天更重要。

Agent 任务为什么特别受影响

AI Agent 和普通聊天不一样。普通聊天通常是一问一答，输入上下文相对有限。 Agent 任务会反复读取项目文件、生成计划、调用工具、检查结果、再修改代码。

这类任务有两个特点：

Token 消耗大；
重复上下文多。

第二点很关键。在代码项目里，模型会反复读取同一批文件、目录结构、错误日志和修改结果。如果平台支持缓存命中，重复输入的成本会大幅下降。

原文里提到一次实际体验：把 DeepSeek V4 Pro 和 Flash 接到 Claude Code 一类工具中，让它拉取一个提示词仓库并做成本地搜索网站。任务最终完成，总成本大约 8 毛多，其中 Pro 缓存命中率达到 98.7%。

这个例子说明了一个现实问题：Agent 任务越像“围绕同一个项目反复工作”，缓存命中越有价值。如果一次生成网站、修 bug、改前端只花几毛钱到几块钱，订阅套餐的吸引力就会下降。

可以用一个简化任务估算差距。假设一次 coding agent 任务包含：

50 万 Token 输入，其中 80% 能命中缓存；
5 万 Token 输出；
不计算工具调用、搜索和平台加价，只看模型 Token 成本。

大致成本如下：

模型	估算成本
DeepSeek V4 Flash	约 $0.03
DeepSeek V4 Pro 促销价	约 $0.09
DeepSeek V4 Pro 原价	约 $0.36
GPT-5.4 mini	约 $0.30
GPT-5.4	约 $1.01
GPT-5.5	约 $1.75
Claude Sonnet 4.6	约 $1.11
Claude Opus 4.7	约 $1.65

这个估算不是说 DeepSeek 在所有任务上都更好。模型质量、工具调用稳定性、长上下文检索能力、代码风格和事实可靠性都要单独评估。但从成本上看，DeepSeek V4 把“让 Agent 多跑几轮”的边际成本压得很低。这会鼓励开发者设计更长流程、更频繁的自检和更多候选方案，而不是每次都担心 Token 账单。

Coding Plan 和 Token Plan 的差别

很多 AI 产品现在会提供两类套餐：Coding Plan 和 Token Plan。

它们的差别大致是：

Coding Plan 通常主要面向编程；
Token Plan 通常覆盖更多能力，例如 STT、TTS、绘图、搜索、embedding、RAG；
STT 是语音转文字；
TTS 是文字转语音；
Coding Plan 往往把用户限制在编程场景里，其他能力还需要另买。

从商业角度看，Coding Plan 更像自助餐。用户预先付一笔固定费用，厂商赌的是大多数人不会把额度用满。有人用得多，有人用得少，平均下来平台仍然能赚钱。

但如果按量 Token 价格足够低，用户就会开始计算：我为什么一定要买套餐？如果一个月真实使用成本只有几块钱、十几块钱，买 40 元、200 元的套餐就不一定划算。

降价为什么会冲击套餐模式

订阅套餐的成立，需要一个前提：用户觉得单次使用很贵，或者不想计算每次调用成本。当 Token 价格高时，套餐看起来更安心。当 Token 价格低到几乎无感时，按量付费反而更自然。

DeepSeek V4 的降价相当于把底牌亮出来：

Agent 任务可以很便宜；
长上下文不一定贵到不能用；
缓存命中可以显著降低成本；
普通开发者不一定需要固定订阅；
模型入口可以从“套餐平台”转向“低价 API”。

这会让做 Coding Plan 的平台不舒服。如果用户发现按量调用更便宜、更自由，就没必要为了一个平台的套餐被绑定。

Flash 和 Pro 怎么选

DeepSeek V4 的一个实用思路，是把 Flash 和 Pro 分工使用。

Flash 适合高频、轻量、可重复的任务：

改 bug；
写前端；
写脚本；
做常规代码理解；
处理较长上下文里的普通信息整理；
跑大量子任务。

Flash 便宜，速度快，而且同样支持很长上下文。对日常 coding agent 来说，很多任务不需要一上来就用 Pro。

Pro 更适合复杂判断和兜底任务：

多轮规划；
复杂 Agent 流程；
多次 function call；
事实核查；
财经研究；
需要更强知识和判断力的内容生产；
高风险代码修改。

一个合理配置是：Flash 负责跑量，Pro 负责兜底。普通任务先用 Flash，遇到长程规划、复杂判断、事实核查或多工具协作时再切 Pro。这样既能控制成本，也能保留模型质量。

DeepSeek 为什么可以这么定价

DeepSeek 和很多大厂的业务结构不同。它没有电商、社交、短视频、云计算、手机、汽车、办公套件、操作系统、浏览器或大规模企业 SaaS 生态。

这意味着它不需要把用户锁在一个完整平台里。它可以只卖文本模型能力：你在这里用便宜的文本模型，其他能力要调用谁都可以。

大厂的逻辑通常不同。如果你买了它的 Coding Plan 或 Token Plan，就会被拉进它的云、搜索、绘图、语音、数据库和开发工具生态。套餐不是单纯卖模型，而是在争夺用户入口。

DeepSeek 的打法更直接：把文本模型价格压低，争取成为 Agent 的默认模型入口。只要默认入口被占住，很多开发者和工具链就会自然围绕它适配。

开源模型和默认入口

DeepSeek V4 如果保持开放模型路线，第三方云厂商和平台很可能会自行部署并提供服务。这对 DeepSeek 来说既是传播，也可能是分流。

低价官方 API 的意义就在这里。如果官方价格已经足够低，其他平台即使能部署，也很难在价格上明显更有优势。用户会倾向于直接使用默认、便宜、稳定的入口。

对 Agent 工具尤其如此。 Agent 任务依赖长上下文、缓存、工具调用和稳定吞吐。一旦某个模型在这些场景里成本足够低，它就有机会成为默认选项。

Coding Plan 仍然不是完全没用

这并不意味着 Coding Plan 会马上消失。它仍然有适合的人群。

如果某些用户真的是高强度使用者，每天把套餐额度打满，那么固定订阅可能仍然划算。就像自助餐，如果完全没有人能吃回本，用户也不会愿意买。

但问题在于，绝大多数用户不是这种极端高频用户。低频用户、轻量开发者、偶尔写脚本或改项目的人，更适合按量付费。当 DeepSeek 把按量成本压低后，套餐的吸引力会被削弱。

未来更可能出现的是分层选择：

高频重度用户继续买 Coding Plan；
普通用户转向低价 API；
Agent 工具根据任务自动选择 Flash / Pro；
平台套餐需要提供更多非模型价值，例如工作流、IDE 集成、部署、团队管理和安全审计。

小结

DeepSeek V4 的发布并没有靠跑分制造最大冲击。真正改变行业预期的是后续降价。

当输入 Token 和缓存命中价格被压到很低时，AI Agent 的使用成本会发生变化。过去看起来昂贵的长上下文、代码项目分析、多轮工具调用，现在可能变成几毛钱到几块钱的日常消耗。

这会直接冲击 Coding Plan 和 Token Plan 的商业逻辑。如果用户可以按量付费、自由组合模型和工具，而且成本足够低，就不一定愿意被绑定在某个平台套餐里。

DeepSeek V4 这次真正动到的，不只是模型能力排名，而是 AI Agent 的成本结构和默认入口之争。

参考来源：

NVIDIA 发布 Nemotron 3 Nano Omni：面向智能体的开放全模态推理模型

Fri, 01 May 2026 12:07:15 +0800

NVIDIA 发布了 Nemotron 3 Nano Omni，这是一款面向智能体工作流的开放式全模态推理模型。它的重点不是只做文字问答，而是把语言、视觉、音频放进同一个推理框架里，让模型能够处理更接近真实工作流的输入。

从定位看，Nemotron 3 Nano Omni 更像是给 AI Agent 准备的底层模型。它可以理解屏幕、文档、图片、语音和视频中的信息，并把这些信息转成可执行的推理结果。这类能力适合计算机操作、文档智能、视频理解、语音交互、客服、教育和企业流程自动化。

模型规格

Nemotron 3 Nano Omni 采用 MoE 架构。 NVIDIA 给出的核心规格是：

项目	信息
模型名称	`Nemotron 3 Nano Omni`
架构	MoE
参数规模	30B total / 3B active
模态	文本、图像、音频、视频
上下文长度	256K token
许可	Apache 2.0
主要部署方向	AI Agent、多模态推理、企业智能体

这里最值得注意的是 30B-A3B。它代表模型总参数规模约 30B，但每次推理只激活约 3B 参数。这能在能力和推理成本之间做一个折中：模型保留较大的专家容量，同时运行时只使用其中一部分。

不过，MoE 的 active params 不等于显存只按 3B 模型估算。完整部署仍然要考虑专家权重、KV cache、视觉/音频编码模块、上下文长度和推理框架开销。

它解决的不是单一模态问题

传统大语言模型主要处理文字。多模态模型进一步支持图片理解。而 Nemotron 3 Nano Omni 的目标更宽：它强调全模态输入，也就是把文本、图像、音频和视频统一纳入推理。

这对 Agent 很关键。真正的智能体任务往往不是“给一段文字，生成一段文字”，而是：

看屏幕上的按钮、表格和窗口；
读 PDF、截图、图表和网页；
听语音说明或会议录音；
理解视频中的动作、场景和时序；
把这些信息综合成下一步操作。

如果模型只能处理单一模态，Agent 就需要额外拼接多个专用模型。全模态模型的价值在于减少这种拼接成本，让同一个模型直接处理更复杂的环境输入。

面向计算机操作和文档智能

NVIDIA 特别提到，Nemotron 3 Nano Omni 可用于计算机操作相关任务。这类任务通常要求模型理解用户界面：

屏幕上有哪些控件；
当前窗口处于什么状态；
哪个按钮或菜单是下一步目标；
表格、弹窗、输入框中的内容意味着什么。

这也是现在 AI Agent 落地时很难绕开的能力。如果智能体要帮人操作办公软件、浏览器、企业后台或开发工具，它必须能看懂界面，而不是只读 API 文档。

文档智能也是类似逻辑。企业资料经常混合文本、表格、图像、扫描页和图表。全模态模型可以把这些内容放在同一个上下文里理解，适合做合同审阅、报表分析、票据处理、知识库问答和流程自动化。

音频和视频让 Agent 更接近真实场景

音频和视频输入会让 Agent 的应用范围明显扩大。

音频场景包括：

会议录音总结；
客服通话分析；
语音指令理解；
教育和培训内容整理。

视频场景包括：

教学视频理解；
安防和工业巡检；
屏幕录制分析；
操作流程复盘；
多步骤任务中的时序判断。

这些任务如果只靠文字转写，会丢掉很多视觉和时序信息。全模态模型可以直接把声音、画面和文字线索结合起来，给 Agent 更完整的环境感知。

部署与生态

NVIDIA 将 Nemotron 3 Nano Omni 放进开放生态里，模型采用 Apache 2.0 许可。这对开发者和企业很重要，因为它降低了试验、集成和二次开发的许可门槛。

从 NVIDIA 的介绍看，这个模型也和其推理生态绑定紧密。对企业用户来说，真正部署时通常会关注这些问题：

是否能在 NVIDIA GPU 上高效推理；
是否支持长上下文和多模态输入；
是否能接入现有 Agent 框架；
是否能处理企业内部文档、音视频和界面截图；
是否可以在私有环境里部署。

NVIDIA 强调该模型在吞吐方面有明显优势，并称其最高可达到同类开放全模态推理模型的 9 倍。这个数字的实际价值，还要结合具体硬件、上下文长度、输入模态和推理框架来看。但方向很明确：NVIDIA 想把开放多模态模型和自己的推理基础设施一起推向企业 Agent 场景。

适合哪些场景

Nemotron 3 Nano Omni 更适合下面这些任务：

需要同时理解文本、图片、音频和视频的 Agent；
企业内部文档智能和知识库问答；
基于屏幕截图或网页界面的计算机操作；
会议、客服、教学内容的多模态分析；
视频理解、流程复盘和时序判断；
对开放许可和私有化部署有要求的团队。

它不一定适合所有普通用户。如果只是本地聊天、代码补全或简单问答，单模态语言模型可能更轻、更快、更省资源。 Nemotron 3 Nano Omni 的价值主要体现在复杂输入和多模态 Agent 工作流里。

这对 AI Agent 意味着什么

AI Agent 要真正进入工作场景，不能只会写文字。它需要看得懂界面，听得懂语音，读得懂文档，理解视频里的变化，还要把这些信息转成下一步行动。

Nemotron 3 Nano Omni 的意义就在这里。它不是单纯把模型参数做大，而是把 Agent 需要面对的多种输入统一到一个推理模型里。这会让开发者更容易构建面向真实任务的智能体，而不是只围绕聊天窗口做应用。

从这个角度看，NVIDIA 发布这款模型的重点不只是“又一个多模态模型”，而是继续把开放模型、GPU 推理、企业 Agent 和私有部署连接起来。未来真正值得关注的是，它在具体 Agent 框架、企业工作流和本地部署中的实际表现。

参考来源：

NVIDIA 技术博客：NVIDIA Nemotron 3 Nano Omni

FinceptTerminal：开源金融终端、量化研究和 AI Agent 工作台

Fri, 01 May 2026 03:47:18 +0800

FinceptTerminal 是 Fincept Corporation 开源的金融终端项目。

从 README 的描述看，它不是一个简单行情面板，而是一个面向金融分析、量化研究、交易工作流和 AI Agent 的综合桌面平台。项目 v4 使用 C++20 和 Qt6 构建原生桌面应用，同时嵌入 Python 生态，用来支持分析、脚本、机器学习和金融建模。

如果要类比，它更接近一个开源金融研究工作台：一边连接数据源，一边做图表、组合、量化、交易、情报分析和自动化工作流。

需要先说明：这类工具可以用于研究、分析、教育和内部工具建设，但不能把任何输出直接当成投资建议。金融市场有风险，数据、模型、策略和执行都需要独立验证。

它解决什么问题

金融研究经常被拆散在很多工具里：

行情数据在一个软件里
研究代码在 Jupyter 里
图表在另一个工具里
组合分析在表格里
交易记录在券商系统里
新闻和情报在浏览器里
AI 分析又在聊天窗口里

这种方式能用，但协作和复现很困难。

FinceptTerminal 想解决的是把这些能力整合到一个桌面终端里，让用户可以在同一个环境中完成数据接入、分析、建模、可视化、Agent 协作和交易相关流程。

它的目标不是替代所有专业系统，而是提供一个可扩展的开源金融终端底座。

技术架构

README 中提到 v4 采用 C++20 和 Qt6。

这意味着它不是纯 Web 面板，而是原生桌面应用。对金融终端来说，原生应用有几个优势：

UI 响应更稳定
更适合复杂窗口和多面板布局
更容易处理本地文件和系统资源
可以嵌入高性能组件
适合长期运行的桌面工作流

同时，项目也嵌入 Python。

这点很关键。金融研究和量化分析里，Python 是事实上的主流语言之一。数据分析、机器学习、统计、回测、图表、金融建模都离不开 Python 生态。C++/Qt 负责应用框架和桌面体验，Python 负责研究与扩展能力，这是一种很实用的组合。

数据连接器

README 中提到项目提供 100+ 数据连接器。

金融终端的价值很大程度取决于数据接入。没有数据，再好的 UI 和模型都只是空壳。

这类连接器通常可以覆盖不同来源：

市场行情
宏观数据
公司财务
新闻与情报
交易所数据
加密资产数据
研究数据源
内部或自定义 API

对用户来说，数据连接器的意义是减少“下载 CSV、手动整理、再导入”的流程，让分析更接近实时和自动化。

不过也要注意，金融数据的质量、授权、延迟、覆盖范围和费用都很关键。使用任何数据源前，都要确认许可和用途边界。

AI Agents 模块

项目强调 AI Agents，这也是它和传统金融终端不同的地方。

传统终端更多是人操作界面，人看数据，人做判断。加入 AI Agent 后，工具可以承担更多辅助任务：

汇总市场信息
解释财报和公告
生成研究摘要
帮助筛选数据
辅助编写分析脚本
组织交易或研究工作流
在多个模块之间传递上下文

这不代表 AI 可以替代研究员或交易员。

更合理的定位是：AI Agent 帮你减少重复整理工作，提供初步分析和交互式查询，但重要结论仍然需要数据验证、模型验证和人工判断。

量化研究能力

FinceptTerminal 也面向量化研究。

量化研究通常包括：

数据清洗
因子构建
策略假设
回测
风险评估
组合优化
交易成本估计
结果可视化

如果一个终端能把数据连接、Python 分析、图表和工作流整合起来，对量化研究会很有帮助。研究者可以在一个环境里从数据到策略验证逐步推进。

不过，量化研究最怕“看起来有效”。一个策略如果没有严格处理样本外验证、交易成本、滑点、幸存者偏差、过拟合和数据泄露，回测再漂亮也不可靠。

所以这类工具应该被当作研究平台，而不是自动赚钱机器。

QuantLib 和金融建模

README 中提到 QuantLib 相关能力。

QuantLib 是金融工程里很常见的开源库，常用于利率、债券、期权、衍生品定价、曲线构建和风险计算等方向。

这说明 FinceptTerminal 不只是看股票行情，也试图覆盖更专业的金融建模场景。

这类能力适合：

金融工程学习
衍生品定价实验
曲线与风险指标计算
投资组合风险分析
研究模型原型验证

但金融建模本身门槛很高。模型参数、市场假设、数据来源和定价逻辑都会影响结果。工具能降低操作成本，不能替代专业判断。

节点工作流

README 中还提到节点式工作流。

节点工作流适合把复杂任务拆成可视化流程：

读取数据
清洗数据
运行模型
生成图表
触发 AI 分析
输出报告
发送通知

对金融场景来说，这种方式有两个优点。

第一，流程可视化。复杂分析不再只藏在一堆脚本里，用户可以看到数据如何流动。

第二，适合自动化。重复研究流程可以被保存、复用和调整。

如果后续能和 Python 脚本、数据连接器、Agent、报告系统结合，这类节点工作流会成为金融终端里很有价值的模块。

交易与组合管理

项目也提到交易和组合相关能力。

这类功能最需要谨慎。

组合管理可以帮助用户理解资产暴露、收益、回撤、波动、相关性和风险集中度。交易模块则可能涉及订单、账户、执行和记录。

但只要触及真实交易，就必须考虑：

数据延迟
订单执行风险
API 权限
交易成本
滑点
流动性
风控限制
审计和日志
策略误触发

开发和研究环境里的交易功能，不应直接等同于生产级交易系统。真正接入实盘前，需要严格测试、权限隔离、风控机制和人工审核。

和 Bloomberg Terminal 有什么区别

很多金融终端项目都会被拿来和 Bloomberg Terminal 对比。

但两者定位不同。

Bloomberg Terminal 的价值不仅是软件界面，还包括：

数据覆盖
数据授权
新闻网络
交易生态
客户支持
金融机构工作流
长期积累的行业信任

FinceptTerminal 更像一个开源金融终端框架和研究平台。它的优势在于可扩展、可定制、可本地化、可与 Python 和 AI 工作流结合。

它不应该被简单理解成 Bloomberg 的免费替代品。

更合理的看法是：如果你想研究金融终端怎么构建，或者想搭建自己的金融分析工作台，FinceptTerminal 提供了一个开源起点。

授权和商业边界

README 中提到项目使用 AGPL 和商业授权模式。

AGPL 对网络服务和衍生作品有明确要求。如果你只是学习、研究或个人实验，问题通常不大。但如果准备把它改造成商业产品、内部平台或对外服务，就需要认真阅读许可证。

特别是金融工具常常会进入企业内部系统。这个时候，开源协议、商业授权、数据授权、模型授权都要一起看，而不是只看代码能不能运行。

适合什么人关注

FinceptTerminal 适合这些人：

想研究金融终端架构的开发者
做量化研究或金融工程实验的人
想把 Python 分析能力嵌入桌面工具的人
想探索 AI Agent + 金融工作流的人
想搭建内部金融分析平台的团队
想学习 C++/Qt 金融应用开发的人

如果你只是想看几只股票的行情，普通行情软件可能更简单。

如果你想理解一个金融终端如何把数据、图表、模型、Agent、交易和工作流整合起来，这个项目就更值得研究。

使用时要注意

第一，先区分研究和交易。

研究环境可以容忍实验和失败，交易环境不能。不要把研究工具未经验证就接入真实账户。

第二，重视数据授权。

金融数据不是随便抓来就能商用。不同数据源有不同授权条款，尤其是行情、新闻、财务和交易所数据。

第三，不要迷信 AI Agent。

AI 可以辅助整理信息，但金融结论必须回到数据、模型、风险和事实验证。

第四，关注安全。

如果工具连接账户、API key、交易接口或内部数据，必须处理好密钥管理、权限隔离、日志和网络边界。

第五，理解开源协议。

AGPL 对商业使用和服务化有重要影响。准备做产品化前，应该先处理授权问题。

参考

Fincept-Corporation/FinceptTerminal

最后一句

FinceptTerminal 值得关注的地方，是它把金融终端、Python 量化研究、AI Agents、数据连接器和节点工作流放进了同一个开源桌面平台设想里。

它更适合作为金融技术研究和内部工具建设的起点，而不是被当成可以直接替代专业金融终端或实盘交易系统的成品。

mattpocock/skills：给 AI 编程 Agent 准备的实用技能集合

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills 是 Matt Pocock 公开的一组 AI 编程 agent skills。

它不是一个完整的应用，也不是一个新的聊天客户端，而是一套可以给 AI 编程助手使用的工作技能。它的思路很实用：把 AI 编程里经常出现的问题拆成一个个小技能，让 Agent 在合适的任务里调用，而不是每次都靠一大段提示词硬撑。

如果你经常使用 Claude Code、Codex、Cursor 或类似的 AI 编程工具，这类 skills 很值得关注。因为真正影响 AI 编程体验的，往往不是“模型会不会写代码”，而是它能不能按你的工作方式推进任务。

它解决什么问题

AI 编程助手很强，但也很容易出问题。

常见情况包括：

还没理解需求就开始改代码
一次性改太多文件
输出解释很多，真正有用的行动很少
遇到报错后盲目尝试
没有及时运行测试或检查
忽略项目里已有模式
为了完成任务引入不必要的抽象
写完代码后没有真正 review 风险

这些问题不一定是模型能力不够，而是工作流没有被约束好。

mattpocock/skills 的价值在于，把这些常见失败模式拆成可以复用的操作方式，让 Agent 在不同场景下更像一个有经验的工程协作者。

Skills 是什么

在 AI Agent 语境里，skill 可以理解成一段可复用的任务说明、工作方法或专业流程。

它不一定是代码插件，也不一定必须调用外部服务。很多时候，一个 skill 就是一套明确规则：

什么时候使用
先做什么
不要做什么
需要输出什么
怎么判断任务完成

这和普通提示词模板有点像，但粒度更接近“任务能力”。

普通提示词模板通常是用户每次临时复制粘贴；skills 则更适合作为 agent 工具箱的一部分，让 Agent 根据任务选择合适流程。

为什么要小而可组合

README 中强调这些 skills 是小而可组合的。

这个方向很重要。

如果一个 skill 试图包办所有事情，它很快就会变成新的大提示词：又长、又模糊、又难维护。小技能的优势是边界清楚。

比如一个 skill 专门负责：

先做计划
修复 TypeScript 错误
运行测试并根据结果修复
做代码 review
总结项目约定
改进提示词
清理无用抽象

这些技能可以按任务组合使用。简单任务只用一个技能，复杂任务再串起来。

这更接近真实工程工作：你不会用同一套流程处理所有问题，而是根据问题选择工具。

保留工程师控制权

这个仓库的一个重要取向，是让工程师仍然掌握控制权。

AI 编程很容易滑向两种极端：

第一种是完全手动。AI 只是帮你写几行代码，所有上下文、计划、验证都靠你自己盯。

第二种是完全放手。你把任务丢给 Agent，让它自己大改一通，最后再面对一堆难以审查的 diff。

skills 的作用是在中间找一个更稳的位置。

它让 AI 承担更多重复流程，但仍然用规则限制它：

先理解任务再动手
先阅读相关文件再改
修改范围要可控
出现不确定时要回报
改完要验证
不能为了炫技重构无关代码

这不是削弱 AI，而是让 AI 的行动更容易被人类审查和接管。

对齐问题

AI 编程失败的第一类问题通常是对齐失败。

用户想要的是一个很具体的改动，但 Agent 可能理解成一个更大的重构；用户只想修 Bug，它却顺手改了样式；用户希望遵守现有架构，它却引入新模式。

Skills 可以在任务开始阶段帮助 Agent 做几件事：

重述目标
找出影响范围
识别已有实现模式
给出计划
明确不做哪些事情

这一步很像工程师开工前的自检。

如果 Agent 连任务边界都没说清楚，就直接写代码，后面很容易越走越偏。

反馈循环问题

AI 写代码不能只靠一次生成。

真实开发里，反馈循环很重要：

改一小步
跑测试或类型检查
看错误
修正
再验证

很多 Agent 失败，是因为它跳过了中间反馈。它一次性改很多内容，然后凭感觉总结“应该可以工作”。

Skills 可以把反馈循环显式写进流程里。比如要求 Agent：

修改后运行相关检查
如果检查失败，先读错误信息
不要盲目改无关文件
每轮修复后重新验证
最后报告验证结果

这会让 AI 编程更像真实调试，而不是一次性作文。

架构控制问题

AI 很擅长生成抽象，也很擅长过度生成抽象。

为了完成一个小需求，它可能新建服务层、工具函数、配置对象、类型包装、适配器，最后让代码比需求本身复杂得多。

这类问题在大型项目里尤其危险。因为 AI 生成的抽象看起来很“专业”，但它可能不符合项目已有风格，也可能增加维护成本。

好的 skills 会提醒 Agent：

优先沿用现有模式
不引入没有必要的新抽象
不顺手重构无关区域
修改要和任务规模匹配
先理解代码再设计结构

这能减少“看起来很工程化，实际上更难维护”的输出。

Review 技能为什么重要

写代码和 review 代码是两种不同状态。

Agent 在写代码时，通常会倾向于证明自己的实现成立。它会解释为什么这样改可以工作，但不一定主动找风险。

Review skill 的意义，是让 Agent 切换角色：

找潜在 Bug
找行为回归
找遗漏测试
找边界条件
找复杂度上升
找和现有约定不一致的地方

这对 AI 编程很重要。因为 AI 生成代码的速度很快，如果没有 review，用户很容易被大量 diff 淹没。

一个好的 review 输出应该优先列问题，而不是先夸实现。它要帮助工程师判断这次改动能不能合并。

和普通 rules 文件有什么区别

很多 AI 编程工具都支持 rules、instructions 或 memory。

这些文件通常记录长期规则，比如：

项目技术栈
命名规范
测试命令
不要修改哪些目录
回答风格偏好

Skills 更偏任务流程。

rules 告诉 Agent “长期应该怎么做”，skills 告诉 Agent “面对某类任务时应该怎么执行”。

两者最好一起用。

比如 rules 里写项目用 pnpm test，review skill 里要求改完后检查测试覆盖。这样 Agent 不仅知道命令，也知道什么时候该用。

适合什么场景

mattpocock/skills 这类仓库适合这些场景：

高频使用 AI 编程工具
经常让 Agent 处理真实代码库
想减少 AI 越界修改
想让 Agent 更主动地验证结果
想把自己的工程习惯沉淀成技能
想学习别人如何设计 agent workflows
想把一堆临时提示词整理成可维护的技能集合

如果你只是偶尔让 AI 写一个小函数，可能不需要专门维护 skills。

但如果你已经把 AI 当成长期开发伙伴，skills 会逐渐变得重要。它们相当于给 Agent 配了一套可复用的工作方法。

怎么借鉴这个仓库

即使你不直接使用其中的每个 skill，也可以从这个仓库学到几件事。

第一，把失败模式写下来。

不要只在 AI 出错时临时抱怨。把它经常出错的模式整理成规则，下一次让 skill 提前防住。

第二，技能要短。

一个 skill 最好解决一个明确问题。越短越容易被正确调用，也越容易维护。

第三，输出格式要清楚。

如果你希望 Agent 先列计划、再执行、最后总结验证结果，就把输出结构写清楚。模糊要求通常会得到模糊结果。

第四，保留人工接管点。

好的 skill 不应该让 AI 独自跑到很远。遇到不确定、影响范围扩大、测试失败或需要产品判断时，应该让它停下来说明情况。

使用时要注意

第一，不要把所有事情都技能化。

太多 skills 会让系统变复杂，Agent 也可能不知道该选哪个。先从最高频、最痛的几个场景开始。

第二，skills 需要迭代。

第一次写出来的 skill 不一定好。看 AI 实际执行效果，再逐步删减、补充和改写。

第三，不要让 skill 替代工程判断。

Skill 可以改善流程，但不能保证实现正确。测试、review、构建检查和人类判断仍然重要。

第四，注意不同 Agent 的差异。

Claude Code、Codex、Cursor、Copilot 对 instructions、skills、rules 的支持方式不同。同一套思想可以复用，但具体格式要按工具调整。

参考

mattpocock/skills

最后一句

mattpocock/skills 值得关注的地方，不是里面某一个神奇提示词，而是它展示了一种更实用的 AI 编程思路：把工程经验拆成小技能，再让 Agent 按场景组合使用。

当 AI 编程从偶尔辅助变成日常工作流，skills 会成为约束 Agent、保留工程师控制权和提升反馈质量的重要工具。

free-claude-code：用代理把 Claude Code 接到 OpenRouter、DeepSeek 和本地模型

Fri, 01 May 2026 03:41:49 +0800

free-claude-code 是一个给 Claude Code 使用的 Anthropic-compatible proxy。

它的思路不是破解 Claude Code，也不是提供官方免费的 Claude 服务，而是在本地启动一个兼容 Anthropic API 形状的代理服务，把 Claude Code 发出的请求转发到其他模型后端。README 中提到的后端包括 NVIDIA NIM、OpenRouter、DeepSeek、LM Studio、llama.cpp 和 Ollama。

简单说，它想解决的是：你喜欢 Claude Code 的终端体验，但希望把模型请求接到别的 provider 或本地模型上。

它解决什么问题

Claude Code 的交互体验很适合开发任务。

它可以在终端里阅读代码、修改文件、执行命令、根据项目上下文推进任务。问题是，很多用户并不一定想始终使用同一个模型后端：

想试试 OpenRouter 上的不同模型
想用 DeepSeek 这类模型降低成本
想把请求接到本地 Ollama
想用 LM Studio 或 llama.cpp 跑本地模型
想在开发环境里统一走一个代理入口
想比较不同模型在 Claude Code 工作流里的表现

free-claude-code 的定位，就是在 Claude Code 和这些模型服务之间加一层兼容代理。

这样 Claude Code 仍然按 Anthropic 风格发请求，代理负责把请求适配到不同后端。

工作方式

可以把它理解成三层：

前端是 Claude Code
中间是 free-claude-code 代理
后端是 OpenRouter、DeepSeek、本地模型或其他模型服务

Claude Code 以为自己在访问一个 Anthropic-compatible API。

代理收到请求后，根据配置选择目标 provider，转换必要字段，再把响应返回给 Claude Code。

这类结构的好处是，你不用改 Claude Code 本身，也不用让每个模型服务都原生支持 Claude Code。只要代理能把接口对齐，就能把更多模型接进同一个工作流。

支持哪些后端

README 中列出的方向包括：

NVIDIA NIM
OpenRouter
DeepSeek
LM Studio
llama.cpp
Ollama

这些后端代表了几类不同使用方式。

OpenRouter 更像模型聚合入口，可以测试不同商业和开源模型。

DeepSeek 适合关注中文能力、代码能力和成本的人。

LM Studio、llama.cpp、Ollama 则偏本地模型路线。它们适合在自己的机器或内网环境里运行模型，减少外部 API 依赖，也方便做离线实验。

NVIDIA NIM 则更偏企业和 GPU 推理部署场景。

为什么是 Anthropic-compatible proxy

Claude Code 本来围绕 Anthropic 的接口和模型习惯设计。

如果你想让它接入其他模型，最直接的问题就是接口不一致：

请求字段不同
模型名称不同
streaming 格式不同
tool use 表达不同
错误返回格式不同
token 和上下文限制不同

代理层的价值就在这里。

它把 Claude Code 这边看到的接口维持在接近 Anthropic 的形状，再在后端做适配。对用户来说，配置一次代理后，就可以在相同 Claude Code 工作流里测试不同模型。

适合什么场景

free-claude-code 适合这些场景：

想用 Claude Code 的终端工作流
想测试非 Anthropic 模型在 Claude Code 里的表现
想降低模型调用成本
想把 Claude Code 接到 OpenRouter
想接入 DeepSeek 等兼容模型服务
想用 Ollama、LM Studio、llama.cpp 跑本地模型
想为团队统一配置一个模型代理入口

如果你只是正常使用官方 Claude Code，并且对模型提供方、成本和本地部署没有特殊需求，那不一定需要这类代理。

但如果你经常比较模型，或者希望让 Claude Code 接入本地和第三方模型，这类工具会很有用。

和直接用 OpenRouter 或 Ollama 有什么区别

直接用 OpenRouter、Ollama 或 LM Studio，通常只是和模型聊天，或者通过 API 调用模型。

free-claude-code 的重点不是替代这些服务，而是把它们接到 Claude Code 这个开发工作流里。

区别在于：

你仍然使用 Claude Code 的终端体验
AI 可以围绕代码仓库执行任务
模型后端可以换成其他 provider
本地模型也有机会进入 Claude Code 工作流
配置集中在代理层，而不是每个工具单独改

所以它更像桥接器，而不是新的聊天客户端。

本地模型要注意什么

把 Claude Code 接到本地模型很有吸引力，但也要注意现实限制。

第一，模型能力差距。

Claude Code 的任务通常不只是聊天，还包括理解代码、规划修改、编辑文件、处理命令输出。本地小模型不一定能稳定完成这些任务。

第二，上下文窗口。

代码任务很吃上下文。模型上下文太小，会导致它读不全文件、漏掉约束，或者在多轮任务里丢失背景。

第三，tool use 兼容性。

Claude Code 工作流依赖工具调用和结构化行为。后端模型即使能聊天，也未必擅长遵循工具调用协议。

第四，速度和硬件。

本地模型的速度取决于机器配置、量化方式和模型大小。代码任务如果响应太慢，体验会明显下降。

所以，本地模型更适合实验、低风险任务和特定场景。真正复杂的代码任务，仍然要根据模型能力谨慎选择。

使用边界

这类项目很容易被标题误解，所以边界要说清楚。

第一，它不是官方 Claude Code 免费额度。

它只是把 Claude Code 的请求转发到其他模型后端。你使用 OpenRouter、DeepSeek、NVIDIA NIM 或其他 API 时，仍然需要遵守对应服务的价格、额度和使用条款。

第二，它不是绕过授权的工具。

使用任何代理工具时，都应该遵守 Claude Code、模型服务商和项目本身的许可协议。不要把它理解成规避官方限制的方式。

第三，代理会处理你的请求内容。

代码、命令输出、项目上下文可能会经过代理和后端服务。部署时要考虑日志、密钥、网络和隐私边界。涉及公司代码或敏感项目时，最好使用受控环境。

第四，不同模型表现差异会很大。

同样的 Claude Code 操作，换一个模型后可能出现完全不同的行为。不要默认所有模型都能替代 Claude。

和 LiteLLM 这类代理有什么关系

从思路上看，free-claude-code 属于“兼容接口代理”这一类工具。

这类工具的共同目标是减少上层应用和底层模型服务之间的耦合。上层应用只需要面对一个相对统一的接口，底层 provider 可以按配置切换。

不同项目的侧重点不同。有的更偏通用模型网关，有的更偏 OpenAI-compatible API，有的专门为 Claude Code 这类工具做适配。

free-claude-code 值得关注的地方，是它把目标场景直接放在 Claude Code 上，而不是做一个泛泛的聊天代理。

适合怎样的用户

它更适合有一定折腾能力的用户：

熟悉 Claude Code
知道 API key 和模型 provider 怎么配置
能理解代理服务的启动和环境变量
能排查网络、端口、模型名称和 streaming 问题
愿意比较不同模型在代码任务里的表现

如果你只想开箱即用，官方配置通常更省心。

如果你愿意搭代理、换模型、调参数，并且想让 Claude Code 进入更多模型环境，这个项目就值得研究。

参考

Alishahryar1/free-claude-code

最后一句

free-claude-code 的价值，不在于“免费”这个词，而在于它把 Claude Code 和更多模型后端之间接了一座桥。

当你想保留 Claude Code 的开发体验，同时测试 OpenRouter、DeepSeek、本地模型或企业推理服务时，这类 Anthropic-compatible proxy 就有了用武之地。

Compound Engineering Plugin：把 AI 编程变成计划、执行、评审的工程循环

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin 是 Every Inc 开源的一个 AI 编程工作流插件。

它关注的不是“让 AI 更快写一段代码”，而是把 AI 编程放进一个更像工程团队的循环里：先计划，再实现，再评审，再把经验沉淀下来。对经常使用 Claude Code、Codex、Cursor、Copilot 这类工具的人来说，这类插件解决的是工作流问题，而不只是提示词问题。

AI 编程工具越来越强，但真实项目里最难的往往不是生成代码，而是让它持续按项目规则做事、理解任务边界、避免重复犯错，并在多轮迭代中积累上下文。

它解决什么问题

很多人使用 AI 编程助手时，流程大概是这样：

直接描述需求
让 AI 改代码
看结果是否能跑
出错后继续补充说明
下次新任务再从头解释一遍

这种方式能完成小任务，但在复杂项目里很容易遇到问题：

需求没有先拆清楚，AI 直接开始改
改完代码后缺少系统性 review
项目规范靠用户反复提醒
同类错误下次仍然出现
多个 Agent 工具之间缺少统一工作方法
经验没有沉淀成可复用规则

Compound Engineering Plugin 想解决的就是这类问题。它把 AI 编程拆成多个阶段，让 Agent 不只是执行命令，而是参与一个更完整的工程流程。

什么是 Compound Engineering

从项目 README 的描述看，Compound Engineering 可以理解为一种 AI 辅助软件开发方法。

它强调一个循环：

计划：先理解目标、拆分任务、确认路径
执行：按计划修改代码、运行命令、处理问题
评审：检查实现质量、风险和测试覆盖
学习：把经验沉淀成后续可复用的规则

这个循环很像真实工程团队的工作方式。

一个靠谱的工程师不会拿到需求就立刻乱改，也不会改完就直接交差。他会先判断影响范围，再动手实现，之后检查风险和测试结果，最后把踩过的坑记录下来。AI Agent 也需要类似约束。

为什么需要插件

提示词可以告诉 AI “请先计划再执行”，但提示词本身不一定稳定。

一旦会话变长、上下文变复杂，模型可能会跳过计划、忽略规则，或者为了完成任务而过度自信。插件的价值在于把流程固化下来，让不同 Agent 环境都能遵循类似方法。

这类插件通常会把工作流拆成命令、规则、模板或子流程。用户不需要每次手写完整提示词，而是通过固定入口触发某个阶段。

比如：

先让 Agent 生成计划
再按计划逐步实现
改完后触发 review
发现问题后返回修正
把值得保留的经验写入记忆或规则

这会让 AI 编程更像“受控协作”，而不是一次性聊天。

支持哪些 Agent 环境

README 中提到，项目支持多个 AI 编程环境，包括：

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

这点值得注意。

很多工作流工具只绑定一个客户端，换工具后规则就不能复用。Compound Engineering Plugin 更像一套跨 Agent 的工程方法，把类似的计划、执行、评审流程带到不同工具里。

如果你同时使用多个 AI 编程助手，这类统一工作流会更有价值。不同工具能力不同，但项目规范、评审习惯和任务拆解方法应该尽量一致。

计划阶段有什么用

计划阶段的价值，是防止 AI 过早动手。

复杂任务里，真正重要的问题通常是：

要改哪些文件
哪些模块可能受影响
现有模式是什么
有没有测试
风险点在哪里
是否需要先阅读文档
能不能拆成更小步骤

如果 Agent 没有先想清楚这些问题，就直接开始写代码，很容易做出看似完成、实际偏离项目结构的实现。

计划并不一定要很长。好的计划应该短、具体、可执行。它的目的不是制造文档，而是让后续实现有边界。

执行阶段要避免什么

AI 执行代码任务时，最容易出现几类问题：

顺手重构无关代码
覆盖用户已有修改
只改 happy path
忽略错误处理
不按项目已有风格写
没有运行必要验证
遇到报错后盲目尝试

工作流插件无法保证这些问题完全消失，但可以通过规则和阶段约束减少发生概率。

比如，执行阶段可以要求 Agent 按计划逐步推进；遇到超出计划范围的发现时，先说明风险；修改共享模块时，补充测试或至少运行相关验证。

这种约束对大型代码库尤其重要。AI 写代码越快，越需要流程来限制它的惯性。

评审阶段为什么重要

很多 AI 编程失败，不是因为代码完全不能运行，而是因为细节有问题：

边界条件没处理
状态更新不一致
API 合约被悄悄改了
测试覆盖不到关键路径
错误提示不清楚
性能或安全风险没有被提到

评审阶段就是把 Agent 从“作者模式”切换到“审查模式”。

作者模式容易为自己的实现找理由；审查模式则要主动找漏洞、回归风险和遗漏测试。把这两个阶段分开，会比让同一个回复里同时完成实现和自我审查更可靠。

对用户来说，评审输出也更有价值。它能帮助你快速判断这次修改是否值得合并，还是需要继续返工。

学习和记忆的意义

项目名字里的 “Compound” 暗示了一个重要想法：工程经验应该复利增长。

如果 AI 每次犯错后只是当场修好，下次又犯同样错误，效率提升就很有限。更好的方式是把有价值的经验沉淀下来：

这个项目的目录约定
某类错误的排查方法
测试命令和注意事项
不要触碰的生成文件
代码风格偏好
常见实现模式

这些经验可以变成规则、记忆、文档或模板。后续任务中，Agent 先读取这些沉淀，再开始工作。

这就是 AI 编程从“单次问答”走向“长期协作”的关键。

适合什么场景

Compound Engineering Plugin 适合这些场景：

长期使用 AI Agent 写代码
一个项目会被多次、多轮修改
希望 AI 先计划再实现
希望改完后自动进入 review 思维
团队想统一 AI 编程流程
同时使用 Claude Code、Codex、Cursor 等多个工具
希望把项目经验沉淀成可复用规则

如果只是偶尔让 AI 写一个小脚本，完整流程可能显得偏重。

但如果你正在把 AI 编程助手当成日常开发伙伴，计划、执行、评审、学习这套循环就会明显有用。

和普通提示词模板有什么区别

普通提示词模板通常解决的是“怎么说清楚任务”。

比如：

请一步步思考
请先阅读文件
请保持代码风格一致
请运行测试
请总结修改内容

这些提示当然有用，但它们还是依赖用户每次正确使用。

Compound Engineering Plugin 更偏工作流层。它把这些要求组织成可重复的过程，并适配不同 Agent 工具。这样你不是每次从零写提示词，而是在一套流程里推进任务。

简单说，提示词模板像提醒，工作流插件像制度。

使用时要注意

第一，不要把流程变成负担。

小任务不一定需要完整计划和长篇评审。好的工作流应该能根据任务复杂度调整，简单问题快速处理，复杂问题再走完整循环。

第二，评审不能替代测试。

Agent review 能发现很多问题，但它仍然可能漏掉真实运行时错误。最终判断还要看测试、类型检查、构建结果和人工审查。

第三，规则要持续清理。

沉淀经验很重要，但规则越积越多也会变成噪声。过时规则、重复规则、只适合某次任务的临时经验，都应该定期整理。

第四，跨工具一致不等于完全相同。

Claude Code、Codex、Cursor、Copilot 等工具能力和交互方式不同。统一的是工作方法，不一定是每个命令、每个配置细节都完全一样。

适合怎样的团队

如果一个团队已经允许 AI Agent 修改真实代码，那么只讨论“哪个模型更强”是不够的。

更应该关心：

AI 修改前是否理解任务
AI 修改中是否遵守项目边界
AI 修改后是否主动审查风险
AI 是否能从历史错误中学习
团队是否有统一的 Agent 使用规范

Compound Engineering Plugin 这类项目的意义就在这里。它把 AI 编程从个人技巧，往团队可复用流程推进了一步。

参考

EveryInc/compound-engineering-plugin

最后一句

Compound Engineering Plugin 值得关注的地方，不是多一个 AI 编程命令，而是把 AI 编程组织成可循环改进的工程流程。

当 AI Agent 开始参与真实项目，计划、执行、评审和经验沉淀会比单次生成代码更重要。

TradingAgents-CN：面向中文用户的多智能体金融交易研究框架

Fri, 01 May 2026 03:14:15 +0800

TradingAgents-CN 是一个面向中文用户的多智能体金融交易研究框架。

它的目标不是给出“买哪只股票”的简单答案，而是用多个 AI Agent 模拟一个更完整的金融分析团队：有人看基本面，有人看技术面，有人关注新闻和情绪，也有人负责风险和最终决策。对想研究 LLM + Agent + 金融分析的人来说，这类项目很适合作为实验入口。

需要先说清楚：这类工具适合学习、研究和辅助分析，不应该被当成实盘交易建议。金融市场有风险，模型输出也可能出错、滞后或过度自信。

它解决什么问题

普通聊天模型当然也能分析股票。

你可以直接问：“帮我分析某某公司能不能买。”模型会给出一段看起来完整的回答。但这种方式有几个问题：

分析链路不透明
不同维度容易混在一起
缺少角色分工
缺少正反观点碰撞
风险提示可能流于形式
很难复现同一套分析流程

TradingAgents-CN 的思路是把金融分析拆成多个角色，让不同 Agent 负责不同角度，再通过协作、讨论和汇总形成分析结果。

这更接近真实投研流程。一个投资判断通常不会只看一条新闻或一个技术指标，而是要结合公司基本面、市场环境、价格走势、资金情绪、政策风险和仓位控制。

多智能体分析是什么意思

多智能体不是简单地让多个模型轮流说话。

更有价值的做法，是给不同 Agent 分配清晰职责。比如：

市场分析 Agent：关注行情走势、价格变化和市场环境
基本面分析 Agent：关注公司业务、财务数据和长期价值
新闻分析 Agent：关注公告、新闻、舆情和事件影响
技术分析 Agent：关注趋势、指标、支撑阻力和交易信号
风险管理 Agent：关注波动、回撤、仓位和不确定性
决策 Agent：综合不同意见，形成最终判断

这样的结构可以减少单个模型“一口气说完所有结论”的问题。

当不同角色围绕同一个标的展开分析时，系统更容易呈现出多维度判断，也更容易暴露分歧。对学习者来说，这比只看一段总结更有启发。

为什么需要中文版本

金融分析和语言环境关系很深。

中文用户关注的资料来源、市场习惯、股票名称、交易制度、新闻表达和常见术语，都和英文环境不同。直接使用英文框架，经常会遇到几类问题：

中文股票名称和代码处理不顺
A 股、港股、美股语境混杂
中文财经新闻理解不稳定
国内数据源接入不方便
输出风格不符合中文用户阅读习惯

TradingAgents-CN 的意义在于把这套多智能体金融分析流程面向中文用户做了适配。它让中文使用者更容易搭建、运行和理解整个交易分析实验流程。

可以用来做什么

这个项目更适合做研究和辅助分析，而不是自动下单。

比较合适的用途包括：

学习多智能体系统如何协作
研究 LLM 在金融分析中的表现
对股票进行多角度信息整理
比较不同模型在投研任务中的差异
搭建自己的金融分析 Agent 原型
复盘某个标的的历史信息和风险点
练习把投研流程拆成可执行任务

如果你正在学习量化交易、金融工程、AI Agent 或 LLM 应用开发，这类项目可以帮助你理解“AI 投研助手”背后的工程结构。

不适合做什么

它不适合被直接当成稳赚工具。

尤其不适合：

直接根据输出满仓买卖
用模型结论替代自己的风险判断
把短期价格预测当成确定结果
忽略交易成本、滑点和流动性
不做回测就接入真实账户
用单次分析结论替代长期投资策略

LLM 擅长整理信息、生成解释、模拟推理流程，但它并不天然拥有稳定预测市场的能力。金融市场里，信息噪声、突发事件和行为博弈都很强，模型输出只能作为参考材料之一。

和普通量化框架有什么区别

传统量化框架更关注数据、因子、回测、组合优化和交易执行。

比如你会定义策略规则：

均线突破
动量因子
价值因子
波动率过滤
止损止盈
仓位管理

然后用历史数据回测策略表现。

TradingAgents-CN 更偏向“智能体分析框架”。它关注的是如何让多个 LLM Agent 围绕金融任务协作，如何模拟投研讨论，如何把新闻、基本面、技术面和风险判断组织起来。

两者不是替代关系。

更现实的用法是：传统量化系统负责可验证的规则和回测，Agent 系统负责信息整理、报告生成、观点对比和辅助决策。最终能不能进入真实交易，还要经过严谨回测、风控和人工审核。

和直接问 ChatGPT 有什么区别

直接问模型的门槛最低，但流程很松散。

你问一次，它答一次。换个问法，结论可能就变了。你很难保证它每次都从同样的维度分析，也很难让它稳定扮演多个互相制衡的角色。

TradingAgents-CN 的价值是把分析流程结构化：

角色更明确
步骤更可复现
信息来源更容易组织
观点碰撞更自然
风险检查更容易单独处理
输出更像一份投研流程结果

这对学习和研究很有用。你可以观察不同 Agent 如何影响最终结论，也可以替换模型、调整提示词、修改角色分工，比较结果变化。

使用时要关注哪些风险

第一，数据质量。

金融分析非常依赖数据。如果行情、财报、新闻或公告数据不完整、不及时，Agent 分析再流畅也可能建立在错误基础上。

第二，模型幻觉。

LLM 可能编造不存在的事实、误解数据含义，或者把旧信息当成新信息。涉及具体股票时，必须回到数据源核对。

第三，过度解释。

模型很擅长给出“看起来合理”的解释，但市场价格变化未必真的来自它列出的原因。不要把事后解释误当成因果证明。

第四，回测和实盘差距。

即便某个策略在历史数据中表现不错，真实交易中仍然会遇到滑点、手续费、流动性、停牌、涨跌停、极端行情等问题。

第五，许可证和商用边界。

README 中提到项目采用混合许可证。个人学习研究和商业使用的条件可能不同。如果准备把它放进商业产品或服务，需要先仔细阅读项目许可证说明。

适合怎样的人研究

TradingAgents-CN 适合这些人：

想学习 AI Agent 架构的开发者
想研究 LLM 金融分析能力的人
做量化交易但想加入自然语言分析的人
想搭建投研辅助工具的团队
想了解多角色协作如何影响决策的人
希望用中文环境实验交易 Agent 的用户

如果你的目标只是获得一个简单的买卖建议，这个项目反而不是最合适的打开方式。它更值得关注的是流程、角色、协作和风险控制，而不是某一次输出的结论。

可以怎么扩展

这类框架后续有很多可扩展方向：

接入更多可靠数据源
增加本地模型支持
加入回测模块
细化 A 股、港股、美股不同市场规则
增加行业分析 Agent
增加组合管理和仓位控制
加强报告引用和数据溯源
把 Agent 结论和传统量化信号结合

真正有价值的金融 AI 系统，通常不是让模型单独决定一切，而是让它嵌入一个可验证、可追踪、可风控的流程里。

参考

hsliuping/TradingAgents-CN

最后一句

TradingAgents-CN 值得关注的地方，不是它能不能预测下一根 K 线，而是它把金融分析拆成了一个多智能体协作流程。

把它当作学习和研究工具，会比把它当作自动赚钱机器更合理。

qmd：给 AI Agent 使用的本地 Markdown 文档搜索工具

Fri, 01 May 2026 03:12:57 +0800

qmd 是一个面向本地 Markdown 文档的搜索工具，重点服务对象是 AI Agent。

它解决的问题很具体：当你的项目里有大量 .md 文档时，AI 编程助手经常不知道该读哪一份、该引用哪一段、哪些说明才是最新的。靠全文 grep 可以找到关键词，但很难理解语义；直接把整套文档塞进上下文，又浪费窗口，还容易混入无关内容。

qmd 的思路是先为 Markdown 文档建立索引，再通过搜索接口把最相关的片段交给 AI 使用。它既可以作为命令行工具使用，也可以通过 SDK 集成，还可以作为 MCP Server 接入支持 MCP 的客户端。

它解决什么问题

真实项目里的文档通常不是一两篇 README。

你可能会有：

架构说明
API 文档
开发规范
部署流程
设计决策记录
故障排查笔记
需求文档
AI 使用说明
各种工具链备忘录

人类查文档时可以顺着目录慢慢看，但 AI Agent 更需要一个明确的检索入口。否则它可能会：

读错文档
漏掉关键约束
使用过时说明
把不相关内容塞进上下文
在回答里凭经验补全不存在的规则

qmd 的价值就在这里：它把本地 Markdown 文档变成可检索的知识源，让 AI 在需要上下文时先搜索，再基于匹配片段回答或执行任务。

搜索方式有什么特点

README 中提到，qmd 使用了多种检索方式组合：

BM25 关键词搜索
向量搜索
LLM reranking

BM25 适合处理明确关键词。比如你搜索某个函数名、配置项、错误码、文件名，它通常很直接。

向量搜索更适合语义问题。比如你问“这个项目怎么处理权限校验”，文档里未必正好写了“权限校验”四个字，但可能有相关的认证、访问控制、角色判断说明。

LLM reranking 则用于重新排序候选结果。前两步先把可能相关的内容找出来，再让模型判断哪些片段更符合当前问题。

这种组合比单纯关键词搜索更适合 AI Agent。因为 Agent 的问题往往不是固定关键词，而是任务意图。

为什么是 Markdown

Markdown 是开发项目里最常见的文档格式。

它足够简单，可以放进 Git；也足够结构化，有标题、列表、代码块、链接和表格。对 AI 来说，Markdown 也比 PDF、网页快照或截图更容易解析。

qmd 专注 Markdown，意味着它可以围绕开发文档做更直接的处理：

按标题和段落切分内容
保留代码块
保留文档路径
返回适合引用的片段
让 Agent 知道答案来自哪份文档

这比让 AI 随机扫描仓库更稳，也比把所有文档一次性塞进 prompt 更省上下文。

三种使用入口

qmd 提供 CLI、SDK 和 MCP Server 三种入口。

1. CLI

CLI 适合直接在终端里使用，也适合放进脚本。

你可以把文档目录索引起来，然后用命令搜索相关内容。对开发者来说，CLI 是最容易验证效果的入口：先看它能不能搜到正确文档，再考虑接入更复杂的工作流。

这类工具放在本地项目里很有用。比如你可以在改代码前先搜索设计文档，在排错前先查故障笔记，在写接口时先查 API 约定。

2. SDK

SDK 适合把 qmd 接入自己的工具。

如果你正在做内部开发助手、文档问答系统、代码审查机器人或项目知识库，可以通过 SDK 调用搜索能力，而不是让用户直接敲命令。

SDK 的好处是可以更自由地控制：

搜索目录
查询内容
返回数量
结果格式
后续是否交给模型总结

这适合需要深度集成的场景。

3. MCP Server

MCP 是 qmd 对 AI Agent 最有价值的入口。

通过 MCP Server，支持 MCP 的客户端可以把 qmd 当作一个文档搜索工具来调用。这样 Agent 在执行任务时，不必猜项目规则，而是可以先检索本地 Markdown 文档。

典型流程可以是：

用户要求 AI 修改某个功能
AI 先调用 qmd 搜索相关设计文档
qmd 返回最相关的 Markdown 片段
AI 基于文档约束再修改代码

这比“开新会话时手动把所有规则贴进去”更自然，也更适合长期项目。

适合什么场景

qmd 适合这些场景：

项目里有大量 Markdown 文档
AI Agent 经常需要查项目规则
团队希望 AI 回答时引用本地文档
文档分散在多个目录里
需要在 CLI、SDK、MCP 之间复用同一套检索能力
想减少 AI 编程助手凭空猜测项目约定
想把本地知识库接入 Claude Desktop、Claude Code 或其他 MCP 客户端

如果你的项目只有一份很短的 README，直接让 AI 读取文件就够了。

但如果文档已经增长到几十篇、几百篇，或者你希望 Agent 每次先查文档再行动，这类索引工具就有意义。

和 grep 有什么区别

grep、rg 这类工具非常适合精确搜索。

比如你知道要找 DATABASE_URL、authMiddleware、404、docker compose，直接搜关键词通常最快。

qmd 更适合你不知道精确词的情况。

例如你想问：

这个项目的发布流程是什么
新增 API 时要遵守哪些规范
之前有没有记录过缓存策略
AI 修改代码前应该读哪些文档
某个模块的设计背景在哪里

这些问题往往需要语义检索，而不是只匹配一个词。qmd 的 BM25 + 向量 + reranking 组合，就是为了让这类问题更容易找到正确上下文。

和 RAG 有什么关系

qmd 可以看作一个面向 Markdown 文档的轻量 RAG 组件。

它不试图替你完成整套问答系统，而是专注在“把相关文档片段找出来”这一步。至于后续怎么使用这些片段，可以交给 CLI、SDK、MCP 客户端或你自己的 Agent 流程。

这种定位比较实用。很多项目并不需要一个庞大的知识库系统，只需要让 AI 在本地文档里查得准一点、快一点，并且能把结果带回当前任务。

使用时要注意

第一，文档质量仍然重要。

检索工具只能帮你找到已有内容。如果文档本身过时、重复、互相矛盾，AI 仍然可能拿到错误上下文。把 qmd 接入 Agent 之前，最好先清理关键文档。

第二，索引范围不要过宽。

把整个仓库所有 Markdown 都塞进去不一定更好。比如依赖包文档、临时记录、旧方案草稿可能会污染结果。更好的做法是明确哪些目录是可信文档源。

第三，搜索结果需要保留来源。

AI 使用文档片段时，最好知道它来自哪份文件、哪个章节。这样人类复核时才能追溯，也能减少“看起来像文档结论，其实只是模型总结”的问题。

第四，不要完全替代人工判断。

qmd 能提高上下文召回质量，但它不是项目真理源的替代品。重要变更仍然要看当前代码、测试结果和最新需求。

适合怎样的团队

如果你的团队已经开始把 AI Agent 放进日常开发流程，qmd 这类工具会很有价值。

尤其是下面几种团队：

文档写得比较多
项目历史比较长
新人和 AI 都需要快速理解背景
经常维护架构决策记录
有大量 Markdown 规范文档
希望 AI 修改代码前先查规则

它的目标不是让 AI “全知全能”，而是让 AI 少猜一点，多查一点。

参考

tobi/qmd

最后一句

qmd 的价值，是把本地 Markdown 文档变成 AI Agent 能稳定调用的搜索入口。

当项目文档从“给人看的说明”变成“给人和 AI 都能检索的上下文源”，AI 编程助手才更容易按项目规则做事。

Claude Code Hooks Mastery：13 个 Hooks 生命周期与自动化控制入门

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery 是一个围绕 Claude Code Hooks 的学习项目。

它不是只给几个零散脚本，而是把 Claude Code 的 hooks 生命周期、配置方式、脚本写法和常见自动化场景放在一起讲清楚。对于想让 Claude Code 更可控、更像工程化助手的人来说，这类资料很值得看。

Claude Code 默认已经能读代码、改文件、跑命令。但如果你想让它在特定时机自动检查权限、拦截危险操作、注入项目规范、运行测试、提醒团队规则，单靠聊天指令就不够稳定。Hooks 的价值就在这里：把“每次都要提醒 AI 的规则”变成可执行的流程。

Hooks 解决什么问题

使用 Claude Code 一段时间后，常见痛点大概有这些：

每次新会话都要重复告诉它项目规则
担心它执行不该执行的命令
希望文件修改前后自动做检查
想在提交前自动跑格式化、测试或安全扫描
想把团队规范写成固定流程，而不是靠口头提醒
想在工具调用前后拿到上下文，做记录或拦截
希望复杂任务可以触发子代理或专门脚本处理

Hooks 就是为这些“固定时机的自动动作”准备的。

你可以把它理解成 Claude Code 工作流里的事件钩子：当会话开始、用户提交提示词、模型准备调用工具、工具调用完成、代理即将结束等节点发生时，Claude Code 可以执行你配置的脚本。

13 个 Hooks 生命周期

项目 README 的重点之一，是系统整理了 Claude Code 的 13 个 hook 事件。

这些事件覆盖了从会话开始到工具调用、从用户输入到代理结束的多个节点。按用途可以粗略分成几类：

会话启动相关：用于初始化环境、注入项目上下文
用户输入相关：用于检查提示词、补充规则、做审计
工具调用前相关：用于权限判断、命令拦截、安全检查
工具调用后相关：用于记录结果、触发格式化、运行验证
任务结束相关：用于总结、清理、通知或保存状态

这种生命周期设计让你不必把所有规则都写进一个超长提示词里。

比如，权限控制应该发生在工具调用前；格式化检查更适合发生在文件修改后；项目规范注入适合发生在会话开始或用户输入后。把规则放到正确的 hook 节点，通常比把所有内容塞进 system prompt 更可靠。

配置文件在哪里

Claude Code 的 hooks 通常通过设置文件配置。

常见位置包括：

用户级配置：~/.claude/settings.json
项目级配置：.claude/settings.json

用户级配置适合放个人偏好，比如通用安全规则、命令拦截、日志路径。

项目级配置适合放仓库相关规则，比如这个项目必须跑什么测试、哪些目录不能改、生成文件怎么处理、提交前要做哪些检查。

如果你在团队里使用 Claude Code，更推荐把项目级配置放进仓库。这样每个人打开项目时，拿到的是同一套 AI 协作约束，而不是各自凭记忆提醒。

单文件脚本为什么重要

项目里强调了 UV 单文件脚本的写法。

这类脚本的好处是部署简单。一个 Python 文件就可以声明依赖并运行，不必为了一个 hook 单独维护复杂环境。对 hooks 来说，这很合适，因为很多 hook 只是做一件小事：

检查命令是否允许执行
判断文件路径是否安全
读取项目规范并返回给 Claude
扫描输出中是否包含敏感信息
在修改后运行格式化或测试
把事件写入日志

Hook 脚本越小，越容易维护，也越不容易变成新的复杂系统。

可以做哪些自动化

claude-code-hooks-mastery 展示的方向比较多，实际工作中最常见的是下面几类。

1. 权限和安全控制

这是 hooks 最直接的用途。

比如在 Claude Code 准备执行命令之前，先检查命令内容。如果命令包含删除、重置、清空、覆盖等高风险动作，就阻止执行或要求人工确认。

类似规则还可以用于文件路径：

不允许修改生产配置
不允许写入密钥文件
不允许删除迁移脚本
不允许触碰指定目录
不允许执行未批准的网络命令

这类保护放在工具调用前，比写一句“不要做危险操作”更可靠。

2. 上下文注入

很多项目都有固定背景：

技术栈
编码规范
测试命令
分支策略
目录结构
禁止事项
生成文件处理规则

这些内容每次手动告诉 Claude Code 很麻烦，也容易漏。Hooks 可以在会话开始或用户提交提示词后，把必要上下文自动注入进去。

这相当于给 Claude Code 配一个项目级的工作说明书。它不会替代 README 或开发文档，但能让 AI 在执行任务前更快进入正确状态。

3. 修改后的验证

当 Claude Code 修改文件后，可以通过 hook 自动触发检查。

常见动作包括：

运行格式化
运行 lint
运行单元测试
检查类型错误
扫描生成文件
校验 Markdown 或 JSON 格式

这对减少低级错误很有帮助。尤其是 AI 改动多个文件时，修改后自动跑一轮轻量验证，可以更早发现问题。

不过也要注意，hook 里不适合默认塞太重的任务。每次文件改动都跑完整测试套件，可能会让体验变得很慢。更实用的做法是按文件类型、目录和任务风险选择检查范围。

4. 团队规则验证

如果团队已经有明确约定，可以把一部分约定放进 hooks。

比如：

提交信息格式
代码风格规则
禁止直接修改某些生成文件
文档必须同步更新
API 变更必须改测试
某些目录只能用指定工具生成

这会让 Claude Code 更像团队流程的一部分，而不是一个不受约束的外部助手。

当然，hooks 不应该替代 CI。它更适合做本地快速提醒和前置拦截，真正的最终验证仍然应该交给 CI、review 和测试系统。

5. 子代理和专门任务

README 里还提到子代理相关内容。

这类用法适合把复杂任务拆给更专门的流程处理。比如主会话负责理解需求，hook 或配置触发专门的检查、审计、总结、文档整理任务。

对个人用户来说，最先值得做的不是复杂代理编排，而是把重复、明确、低风险的动作交给 hooks。等规则稳定后，再考虑更复杂的自动化。

Statusline 和输出样式

项目还覆盖了状态栏和输出样式。

这部分看起来像体验细节，但对长期使用 Claude Code 很有意义。状态栏可以展示当前上下文、任务状态、环境信息或提示信息；输出样式则可以让 Claude Code 的回答更符合你的工作习惯。

如果你每天都在同一个终端里和 AI 协作，这些细节会影响效率。好的状态提示能减少误操作，也能让你更快判断当前会话是否处在正确项目、正确分支、正确环境里。

不要把 hooks 写得过重

Hooks 很强，但不适合什么都往里面塞。

比较好的规则是：

高频动作要快
安全拦截要明确
输出要短
失败原因要可读
脚本尽量单一职责
重型检查交给显式命令或 CI

如果一个 hook 每次都执行十几秒，用户很快就会想关掉它。如果一个 hook 拦截规则含糊不清，Claude Code 和用户都会难以理解下一步该怎么做。

Hooks 最适合处理那些边界清楚的事情：允许或拒绝、补充上下文、记录日志、运行轻量检查、提示下一步。

适合怎样的使用者

如果你只是偶尔让 Claude Code 改一小段代码，可能暂时不需要深入 hooks。

但如果你符合下面几种情况，就很适合研究这个项目：

高频使用 Claude Code
经常让 AI 修改真实项目代码
担心 AI 执行危险命令
想把团队规范自动注入 AI 工作流
希望修改后自动跑检查
想把重复提醒变成配置
正在搭建更稳定的 AI 编程流程

尤其是多人协作项目，hooks 的意义会更明显。它可以把一部分团队经验沉淀成脚本，而不是靠每个人临时提醒 AI。

使用时要注意

第一，先从安全类 hook 开始。

相比复杂自动化，命令拦截、路径保护、敏感文件检查更容易落地，也更能立刻降低风险。

第二，项目级规则要谨慎提交。

.claude/settings.json 会影响所有使用这个仓库的人。把规则提交前，最好确认它不会过度限制正常开发，也不会依赖只有你本机才存在的路径。

第三，hook 输出要简洁。

Claude Code 会消费这些输出。输出太长，会污染上下文；输出太模糊，又起不到指导作用。最好只返回必要判断和下一步建议。

第四，保持可调试。

Hooks 一旦变多，问题可能出在配置、脚本、权限、路径、依赖或 Claude Code 本身。给脚本留下清晰日志，会让后续排查轻松很多。

参考

disler/claude-code-hooks-mastery

最后一句

Claude Code Hooks 的价值，是把“希望 AI 每次都记住的规矩”变成真正会执行的流程。

如果你已经开始把 Claude Code 用在真实项目里，hooks 会是从“会聊天的编程助手”走向“可约束的工程协作者”的关键一步。

Claude-Mem：给 Claude Code 加上跨会话长期记忆

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem 是一个给 Claude Code 使用的持久化记忆系统。

它想解决的问题很具体：AI 编程助手每次开新会话时，往往会忘记之前讨论过的架构决策、踩过的坑、项目偏好和实现背景。
如果一个项目做得久，每次都重新解释上下文，非常浪费时间。

Claude-Mem 的思路是：把 Claude Code 的会话内容压缩成记忆，存进本地数据库和向量库，之后再通过搜索工具找回来。

它解决什么问题

Claude Code 很适合处理代码任务，但会话上下文毕竟有限。

常见痛点包括：

新会话不知道旧会话做过什么
项目里的设计决策需要反复解释
曾经排查过的问题容易重复踩
长期任务缺少连续记忆
多次对话之间很难沉淀项目知识

Claude-Mem 就是围绕这些问题设计的。

它不是简单保存聊天记录，而是把会话压缩成更容易检索的记忆片段。这样后续需要时，可以通过语义搜索把相关上下文找回来。

工作方式

从 README 的设计看，Claude-Mem 主要由几部分组成。

第一部分是 hooks。

它会接入 Claude Code 的会话流程，在合适的时机捕获会话数据。

第二部分是后台 worker。

worker 负责把原始会话内容处理成更短、更可检索的记忆。

第三部分是本地存储。

项目使用 SQLite 保存结构化元数据，用 Chroma 保存向量索引。这样既能保留会话记录的基本信息，也能支持语义检索。

第四部分是 mem-search。

这是给 Claude Code 使用的查询入口。需要找回旧上下文时，可以通过它搜索相关记忆。

整体流程可以理解为：

Claude Code 会话产生内容
hooks 捕获会话数据
worker 异步压缩和整理
记忆写入 SQLite 与 Chroma
后续通过 mem-search 检索

适合什么场景

Claude-Mem 适合长期项目，而不是一次性小任务。

比如：

一个仓库持续开发很多天
代码结构复杂，背景说明很多
需要记住项目约定、命名习惯和架构选择
经常让 Claude Code 修 Bug、写功能、整理文档
希望 AI 能记住“之前为什么这么改”

如果你只是临时让 Claude Code 改一行代码，长期记忆意义不大。
但如果你把 Claude Code 当作长期协作者，它就会变得有用。

安装和启动

README 中给出的安装方式很直接：

1
2

npm install -g claude-mem
claude-mem install

启动时可以使用：

`1`	`claude-mem start`

查看状态：

`1`	`claude-mem status`

如果需要停止：

`1`	`claude-mem stop`

这些命令背后的目标，是把记忆系统作为一个长期运行的本地服务接到 Claude Code 工作流里。

`mem-search` 怎么用

mem-search 是找回记忆的关键入口。

它的用途不是替代普通搜索，而是让 Claude Code 能按语义查询过去会话中的内容。

比如你可以让 Claude Code 查询：

某个模块之前为什么这样设计
某个 Bug 当时怎么排查
项目里约定的命名规则
之前讨论过的技术取舍
某次重构的背景原因

这种查询和简单关键词搜索不同。
如果记忆压缩和向量索引做得好，即使你不记得原话，也能找回相近语义的内容。

和普通项目文档有什么区别

项目文档适合记录稳定结论。

比如：

架构说明
部署流程
API 约定
数据库结构
开发规范

Claude-Mem 更适合记录会话过程中产生的上下文。

比如：

为什么某个方案被放弃
某个临时问题怎么绕过
某个实现背后的讨论过程
还没来得及写进文档的项目偏好
多次对话里积累出的任务背景

两者不是互相替代。
比较好的方式是：稳定知识写进项目文档，过程性上下文交给记忆系统辅助检索。

使用时要注意什么

第一，长期记忆不是越多越好。

如果所有对话都无差别保存，后续检索可能会变得嘈杂。真正有价值的是项目决策、实现背景、问题排查和长期偏好。

第二，记忆不能替代代码和文档。

AI 搜到的旧上下文只能作为参考。最终判断仍然要看当前代码、测试结果和最新需求。

第三，隐私和本地数据要注意。

既然它会保存会话内容，就要清楚哪些项目适合接入，哪些敏感信息不应该进入对话。

第四，记忆系统需要维护。

随着项目推进，旧记忆可能过时。过时的上下文如果被误用，反而会误导后续任务。

为什么这类工具值得关注

AI 编程工具正在从“单次问答”走向“长期协作”。

单次问答里，模型只要回答当前问题就够了。
长期协作里，它需要知道项目历史、之前的决策、团队偏好和已经踩过的坑。

Claude-Mem 这类工具的意义就在这里：它把“记住上下文”从临时聊天能力，变成一个可以安装、运行、检索的本地系统。

对真实工程项目来说，这比单纯让模型上下文窗口变长更实用。
因为很多信息不是一次性塞进上下文就好，而是需要在合适的时候被找回来。

适合谁尝试

如果你符合下面几种情况，可以考虑试试：

高频使用 Claude Code
经常跨天处理同一个项目
项目上下文比较复杂
经常需要向 AI 重复解释背景
想把会话里的经验沉淀下来

如果你只是偶尔使用 Claude Code，或者项目很小，暂时不一定需要这类系统。

参考

thedotmack/claude-mem

最后一句

Claude-Mem 的重点不是“保存聊天记录”，而是让 Claude Code 能在后续任务里找回有用上下文。

当 AI 编程从一次性任务变成长期项目协作，记忆系统会越来越重要。
它不能替代文档和测试，但可以减少重复解释，让 AI 更像一个了解项目历史的助手。

Claude.md 不是越长越好：AI 编程全局记忆文件该怎么写

Wed, 29 Apr 2026 21:07:37 +0800

最近看到一个关于 AI 编程全局记忆文件的讨论：项目里使用 Claude.md、AGENTS.md 这类文件之后，效果不一定会变好，甚至可能让成功率下降，同时推理成本还会上升。

这件事乍一看有点反直觉。我们通常会觉得，给 AI 更多项目背景、更多规则、更多说明，它应该更容易写对代码。
但实际问题在于：Claude.md 不是普通文档，而是每次对话都会被塞进上下文的全局记忆。它写得越多，模型每次都要读得越多；它写得越含糊，模型每次都要多做判断；它写进了不该写的流程，模型还可能在不相关的任务里触发多余动作。

所以，Claude.md 真正难写的地方，不是怎么把内容写全，而是怎么判断哪些内容值得长期占用上下文。

Claude.md 到底是什么

在 AI 编程工具里，Claude.md、AGENTS.md 这类文件本质上都是全局记忆文件。

普通对话会进入上下文，但上下文长度有限。对话长了以后，历史内容会被压缩，部分细节会丢失。全局记忆文件的作用，是把一些重要规则固定下来，让模型在每次任务开始时都能看到。

这意味着两件事：

写进去的内容更不容易被遗忘
写进去的内容也会在每次任务里产生成本

它不像一份 README，只在需要时被阅读。它更像一套长期有效的工作约束。只要放进去，就默认每次都会影响模型的判断。

因此，Claude.md 不是项目介绍，也不是经验合集，更不是把所有开发流程都塞进去的地方。它应该只存放那些模型如果不知道，就容易反复犯错的规则。

为什么写了反而可能变差

全局记忆文件写得不好，主要会带来三类问题。

第一，它会占用上下文。

如果 Claude.md 有一千行，那么这些内容会长期进入模型上下文。真正与当前任务有关的代码、错误信息、需求说明，反而会被挤压。上下文不是免费的空间，越大的全局规则，越容易稀释当前任务的重点。

第二，它会触发多余行为。

比如在全局文件里写：

1
2

每次开始任务前，都要完整阅读项目目录。
每次修改后，都要执行完整链路测试。

这些话看起来很负责，但放在全局记忆里就会变成“所有任务都默认执行”。哪怕只是改一行文案，模型也可能因为这条规则去做不必要的探索和测试。结果就是任务变慢、成本变高，甚至引入新的干扰。

第三，它会增加判断负担。

像“保持代码优雅、简洁、可维护、可扩展”这类话，听起来正确，但实际约束很弱。模型每次生成代码时都要判断什么叫优雅、什么叫可扩展，却没有得到明确边界。

更好的写法不是堆抽象美德，而是写具体禁令或反例。比如：

1
2
3

不要为了单个调用点新增通用抽象。
不要在没有测试覆盖的情况下改动共享解析逻辑。
不要把临时脚本放进业务源码目录。

这些规则更具体，也更容易被执行。

应该写什么

判断一条内容要不要写进 Claude.md，可以用一个简单标准：

如果不写，AI 就会反复犯同一种错误，那它值得写进去。

适合写进全局记忆文件的内容，通常有这些特点：

长期有效
与当前仓库强相关
无法从代码结构自然推断
能明确改变模型行为
最好是约束、禁令、路径规则或固定命令

比如：

所有 Hugo 文章只改 index.zh-cn.md，不自动生成其他语言版本。
文章 front matter 必须包含 title/date/draft/tags/categories/slug/description。
不要修改 public/ 目录里的构建产物。
PowerShell 下执行部署时使用 scripts/deploy.ps1。

这些内容不是泛泛而谈，而是和仓库的真实工作方式绑定。模型如果不知道，就可能做错；模型知道以后，确实能减少误操作。

不该写什么

很多人容易把 Claude.md 写成项目说明书，这通常没有必要。

不太适合写进去的内容包括：

项目愿景和背景介绍
大段目录结构说明
临时任务计划
一次性的调试步骤
抽象的代码审美要求
只在少数情况下才需要执行的长流程

比如“这是一个电商项目，包含商品、订单、用户模块”这种描述，对模型完成具体编码任务帮助有限。真正开发时，模型应该根据当前需求、规格文档、代码结构和测试来判断，而不是靠全局记忆里的粗略介绍。

目录结构也是类似。除非某个目录有特殊约定，比如“共享组件只能从这个目录引用”，否则没必要把整个树形结构写进去。模型可以自己读取项目目录，硬塞一份静态目录说明反而容易过期。

流程更适合做成技能或命令

如果一段内容是“第一步做什么、第二步做什么、第三步做什么”，它未必适合放进 Claude.md。

长期流程可以沉淀成技能、脚本或命令。这样做的好处是：全局记忆里只需要保留名称和触发条件，真正的详细步骤只在需要时加载。

比如：

1
2

当用户要求翻译 Hugo 文章时，使用 post-translate 技能。
当用户要求部署站点时，运行 hugo-rsync-deploy 流程。

这比把完整翻译流程、部署流程都写进 Claude.md 更轻。全局记忆保持短，具体流程交给可触发的工具。

Claude 最近的初始化流程也在往这个方向走：不只是生成一个 Claude.md，还会尝试把可复用流程拆成 skills，把固定事件拆成 hooks。这个变化背后的思路很清楚：全局记忆只做入口，细节按需加载。

Claude.md 需要持续迭代

Claude.md 不应该一次写完就不管。

更合理的方式是先保持简短，让模型在真实任务里暴露问题。某个错误出现一次，可以先人工处理；如果同类错误出现两次以上，就说明它可能值得沉淀为全局规则。

这类迭代比一开始写一大堆规则更有效。因为一开始你不知道哪些规则真的有用，也不知道哪些内容会变成噪音。随着项目变大、协作变多、模型行为逐渐稳定，再慢慢把高频问题写进去。

还有一个重要趋势：模型越强，全局记忆文件反而应该越短。

以前很多需要写进提示词的要求，现在模型已经能自然做到。继续把这些基础要求塞进 Claude.md，只会增加上下文负担。全局记忆应该随着模型能力提升而收缩，只保留这个仓库独有、模型无法自动推断的部分。

一个更实用的写法

写 Claude.md 时，可以按这个顺序思考：

这个仓库有什么特殊约定？
哪些错误模型已经犯过不止一次？
哪些目录、文件或命令绝对不能误用？
哪些流程应该改成技能、脚本或命令，而不是常驻上下文？
哪些内容只是介绍，可以删掉？

最后得到的文件，可能只有几十行。它不需要完整解释项目，而是要精确约束行为。

一个好的 Claude.md，应该像这样：

# 工作规则

- 只改与当前任务相关的文件。
- 不要修改 public/、resources/ 这类构建产物目录。
- Hugo 文章改写只处理 index.zh-cn.md，不生成其他语言版本。
- 如果涉及部署，先运行 hugo 构建，再执行既有 rsync 脚本。
- 遇到已有用户改动时，不要回滚，必须基于现状继续修改。

它短，但每一条都能影响实际行为。这样的内容才值得长期占用上下文。

最后一句

Claude.md 的价值不在于让 AI “知道更多”，而在于让 AI “少犯固定错误”。

它不是知识库，也不是项目百科，而是 AI 编程过程里的长期约束文件。
写得越具体、越短、越贴近真实错误，它越有用；写得越泛、越长、越像项目介绍，它越可能拖慢模型，甚至让结果变差。

把全局记忆当成稀缺资源，而不是无限草稿纸。这大概就是写好 Claude.md 最重要的一条原则。

Codex 开始控制电脑，对以后意味着什么？

Wed, 29 Apr 2026 11:28:25 +0800

Codex 这次最值得关注的变化，不是又多了一个普通按钮，而是它开始往“控制电脑”这个方向走。

以前我们使用 AI，更多是在聊天框里提问、复制、粘贴、再手动操作软件。
现在这个边界开始往外扩：AI 不只是回答你，而是可以根据你的目标去操作桌面应用。

这件事短期看是一个新功能，长期看可能会改变很多人使用电脑的方式。

这个功能是什么

简单说，Codex 的电脑使用能力，就是让它能接触并操作桌面环境。

它可以做的事包括：

可以选择并控制某个应用
可以用自然语言下达任务
可以打开浏览器、AI 工具、本地文件或其他软件
可以输入内容、点击按钮、等待结果
可以把多个步骤串成一个任务
可以在后台继续执行，不需要用户每一步都手动跟着

它的定位不是单纯替你写一段文本，而是替你完成一段操作流程。

这就是 Agent 和普通聊天机器人的关键区别：
聊天机器人主要给答案，Agent 更接近“拿到目标后去执行”。

为什么这件事重要

过去很多自动化都要求你会写脚本。

比如你想完成一个跨软件流程：

打开网页
找资料
复制内容
交给另一个 AI 工具处理
保存文件
再打开本地目录检查结果

如果要自动化这件事，传统做法可能是写浏览器脚本、调用 API、写本地程序，甚至还要处理各种软件窗口。

但很多普通用户不会写这些东西。
就算会写，也未必值得为一个临时任务专门写脚本。

电脑使用能力的意义就在这里：它把“脚本能力”往自然语言方向推了一步。

你不一定要告诉它每一步怎么点。
你可以告诉它你要什么结果，让它自己去尝试完成。

它能改变哪些工作流

我觉得最先被改变的，不会是特别严肃、特别高风险的工作，而是那些“烦、杂、重复、但又不值得专门写程序”的流程。

1. 跨软件搬运

最典型的就是在多个软件之间搬信息。

以前你可能要在浏览器、文档、聊天窗口、本地文件夹之间来回切。
以后可以把这类任务交给 Agent：

去找某类资料
汇总成文档
保存到指定目录
打开结果给你确认

这类工作不难，但很耗注意力。
Agent 的价值就是把这些碎操作吃掉。

2. 多个 AI 工具协同

现在很多人的真实工作流已经不是只用一个 AI。

可能是：

一个工具写代码
一个工具查资料
一个工具生成图片
一个工具整理文档

以前这些工具之间靠人肉复制粘贴。
以后 Agent 可以成为中间层：它负责打开工具、传递上下文、等待输出、整理结果。

这会让“多个 AI 协同”从手工流程变成半自动流程。

3. 办公软件自动化

表格、PPT、文档、邮件，这些软件都有一个共同特点：功能很强，但很多操作很碎。

如果 Agent 能稳定控制这些软件，以后的办公自动化门槛会明显下降。

你不用记菜单在哪里，也不用学复杂快捷键。
你只需要说清楚目标，比如：

把这份表格整理成月报
根据这份文档做一页总结
把这些资料合并成一个结构清楚的说明

真正麻烦的按钮操作，会逐渐被隐藏到自然语言后面。

对普通用户意味着什么

对普通用户来说，这类功能的影响可能比“模型又聪明了一点”更直接。

因为它降低的不是知识门槛，而是操作门槛。

很多人不是不会表达需求，而是不知道软件里该点哪里、怎么组合功能。
Agent 如果能接管这部分，人使用电脑的方式就会变成：

1
2
3

我描述目标
Agent 操作软件
我检查结果

这比单纯聊天更接近真实生产力。

对软件形态的影响

如果这类 Agent 能力继续成熟，软件本身也会被反向影响。

过去软件设计主要服务人类点击。
以后软件可能还要服务 Agent 操作。

这意味着：

界面元素需要更清晰
操作反馈需要更稳定
本地权限需要更细
软件可能会提供更适合 Agent 调用的接口
用户会更在意“能不能被 AI 顺利操作”

长期看，应用之间的边界可能会变薄。
用户关心的不再是“我打开哪个软件”，而是“我要完成什么任务”。

现在还不能过度乐观

当然，现在还不到完全放手的时候。

这类能力目前还有几个明显限制：

稳定性还需要观察
复杂任务可能中途出错
权限边界必须谨慎
涉及账号、支付、删除文件等操作不能随便放权
额度消耗也不是完全可以忽略

所以现阶段最合适的用法，不是让它完全接管电脑，而是让它处理低风险、可检查、步骤繁琐的任务。

比如：

整理资料
生成草稿
跨工具搬运内容
打开和检查文件
做一些可以人工复核的半自动流程

最后一句

Codex 这次更新真正重要的地方，是它把 AI 从“回答问题”推向了“操作环境”。

短期看，它是一个电脑使用功能。
长期看，它可能是个人电脑交互方式的一次转向。

以后我们使用电脑，可能会越来越少地记按钮、找菜单、切窗口。
更多时候，我们只需要说清楚目标，然后让 Agent 去执行，再由人做最后判断。

Codex Skill 明明在目录里，为什么就是不显示？

Wed, 29 Apr 2026 11:18:00 +0800

这次遇到的问题很隐蔽：~/.codex/skills 里明明已经放好了多个 skill，新开 Codex 线程之后，侧边栏却还是只能看到少数几个。

一开始看起来像是缓存或索引问题，但实际原因更具体：几个 SKILL.md 文件开头带了 UTF-8 BOM，Codex 0.111.0 的 skill loader 没有跳过这个字节，于是误判文件没有合法的 YAML front matter。

现象

本地目录里有这些 skill：

~/.codex/skills/git-commit-push/SKILL.md
~/.codex/skills/hugo-rsync-deploy/SKILL.md
~/.codex/skills/bilibili-speech-transcriber/SKILL.md
~/.codex/skills/product-cutout-normalize/SKILL.md

但新开线程时，实际暴露出来的只有：

1
2

bilibili-speech-transcriber
product-cutout-normalize

也就是说，文件存在不等于当前会话一定能加载成功。Codex 会先解析每个 SKILL.md 的 front matter，解析失败的 skill 会直接被排除。

排查

用 codex exec 启动一个新会话时，可以看到更直接的错误（在vscode等IDE中可能看不到这些log）：

1
2

failed to load skill C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md: missing YAML frontmatter delimited by ---
failed to load skill C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md: missing YAML frontmatter delimited by ---

这些文件肉眼看起来都有正常的开头：

---
name: post-rewrite
description: ...
---

真正的问题在字节层面。

失败文件的开头是：

`1`	`EF-BB-BF-2D-2D-2D`

能正常加载的文件开头是：

`1`	`2D-2D-2D`

2D-2D-2D 就是 ---。前面的 EF-BB-BF 是 UTF-8 BOM。

原因

Codex 0.111.0 的 skill loader 当前要求 SKILL.md 文件第一个字节就是 --- 的第一个 -。

如果文件前面带了 UTF-8 BOM，那么文件实际开头就不再是 ---，而是：

`1`	`BOM + ---`

于是 loader 会认为它没有以 front matter 分隔符开头，最后报：

`1`	`missing YAML frontmatter delimited by ---`

这不是 skill 内容写错了，也不是目录放错了，而是编码细节让解析器没认出来。

修复

把出问题的 SKILL.md 转成无 BOM 的 UTF-8 即可。

PowerShell 可以这样处理：

$paths = @(
  'C:\Users\knightli\.codex\skills\git-commit-push\SKILL.md',
  'C:\Users\knightli\.codex\skills\hugo-rsync-deploy\SKILL.md',
)

$utf8NoBom = New-Object System.Text.UTF8Encoding($false)

foreach ($p in $paths) {
  $text = [IO.File]::ReadAllText($p, [Text.Encoding]::UTF8)
  [IO.File]::WriteAllText($p, $text, $utf8NoBom)
}

处理后再检查文件头，应该从：

`1`	`EF-BB-BF-2D-2D-2D`

变成：

`1`	`2D-2D-2D`

验证

重新启动一个 Codex 会话后，可见 skill 恢复为：

git-commit-push-zh
hugo-rsync-deploy
bilibili-speech-transcriber
product-cutout-normalize

如果侧边栏仍然只显示旧的列表，可以退出当前 Codex sidebar 或窗口，再重新打开项目。skill 列表通常在会话启动时加载，中途改文件不一定会立刻刷新到当前线程。

最后一句

这类问题最容易误判成“Codex 没重新索引”或“skill 没安装好”。

实际排查时可以先看三件事：

SKILL.md 是否真的在正确目录
文件头部是否有合法的 --- front matter
文件是否是无 BOM 的 UTF-8

这次的关键就是第三点：文件看起来没问题，但第一个字节不是 -，Codex 就没有把它当作一个有效 skill。

Codex 里的 ~/.codex/skills 和项目/.codex/skills 有什么区别

Wed, 29 Apr 2026 11:08:00 +0800

很多人整理 Codex skills 时，最容易卡住的问题就两个：

~/.codex/skills 和 项目/.codex/skills 有什么区别
为什么 skill 明明在目录里，当前会话里却不一定显示

这篇就直接说结论。

两者的区别

先记最短版本：

~/.codex/skills 是你的全局技能库
项目/.codex/skills 是这个仓库的本地技能库

`~/.codex/skills`

适合放：

你自己跨项目反复会用的 skill
跟具体仓库无关的通用流程
很明显属于你个人习惯的工作流

比如：

post-rewrite
post-translate
git-commit-push
hugo-rsync-deploy
bilibili-speech-transcriber

这类 skill 的特点就是：离开当前项目也还能用。

`项目/.codex/skills`

适合放：

只对这个仓库成立的流程
跟当前项目目录结构、脚本、模板绑定很深的规则
需要让团队一起共享的 skill

比如：

这个仓库特有的发布流程
只能在这个项目里用的生成模板
跟项目私有脚本强绑定的自动化步骤

这类 skill 的特点是：离开这个仓库就没意义。

什么时候放全局，什么时候放项目里

直接这样判断就够了：

跟你个人习惯有关，放 ~/.codex/skills
跟仓库规则有关，放 项目/.codex/skills
能跨项目复用，优先放全局
要多人共享、跟仓库一起演进，优先放项目里

当前这个仓库是什么情况

按我现在看到的实际状态：

你的本机里有 ~/.codex/skills
当前仓库里没有 .codex/skills

所以你现在主要依赖的是全局 skills。
也就是说，像 post-rewrite、post-translate、git-commit-push 这些流程，现在更多是你个人工作流的一部分，不是这个仓库显式自带的一部分。

为什么磁盘里有，当前会话里却不一定显示

这里要分清两件事：

磁盘存在：说明 skill 文件在本地目录里
会话暴露：说明当前会话把它注册进了可用 skill 列表

这两者不是一回事。

所以会出现这种情况：

~/.codex/skills 里已经有 skill
但 / 后面的列表里没有显示

这通常不代表 skill 坏了，更常见的原因是：当前会话没有把它重新索引进去。

怎样让 skill 被当前会话暴露

最实用的步骤就这几条：

1. 目录放对

全局：

`1`	`~/.codex/skills/<skill-name>/SKILL.md`

项目级：

`1`	`项目/.codex/skills/<skill-name>/SKILL.md`

2. `SKILL.md` 头部可识别

最少要有：

---
name: your-skill-name
description: 这个 skill 是干什么的
---

3. 新建或修改后，开新会话

很多时候 skill 没显示，不是文件有问题，而是当前会话启动时就已经把可用 skill 列表定下来了。
所以你中途新建 skill，磁盘里虽然已经有了，这次会话也未必会重新认。

最稳的做法就是：

放好 skill
结束当前会话
重新进入项目
开一个新会话
再看 / 里有没有出现

4. 项目 skill 最好提前放好

如果你想让 项目/.codex/skills 更稳定地被识别，最好在进入仓库、启动会话之前，就把这些 skill 放进项目里。

最后一句

最短结论就是：

~/.codex/skills 是你的个人技能库
项目/.codex/skills 是仓库的本地规则库
skill 在目录里，不等于当前会话一定会显示
想让它显示，最常见的办法就是放对目录、写好 SKILL.md，然后开新会话

Ralph 和多智能体协同：怎么让 AI 长时间稳定工作

Mon, 27 Apr 2026 08:19:02 +0800

如果你最近在折腾 coding agent，很快就会遇到一个现实问题：AI 当然能干活，但怎么让它连续干几个小时，还不在中途跑偏、忘要求、返工一堆？

围绕 Ralph 和多智能体协同的这类讨论，真正值得看的也正是这个问题。它不是单纯比较某个模型有多强，而是把重点放在一层更实际的东西上：怎么设计工作流，才能让 AI 在长任务里保持稳定输出。

把这个问题拆开看，常见的路线主要有两条：

Ralph 方案：不断启动新会话，通过文件系统衔接上下文
多智能体方案：主 Agent 做协调，子 Agent 分工执行

如果把它压成一句更好理解的话，这期内容讲的其实不是“哪个模型更厉害”，而是“怎么把 AI 组织起来，让它更像一个能持续交付的小团队”。

01 为什么长时任务容易失控

短任务里，很多问题不明显。你给一句指令，模型读几份文件，改几行代码，事情也就结束了。

但任务一旦拉长，问题会集中冒出来：

会话越来越长，上下文开始膨胀
早先的要求被新信息挤掉
一个 Agent 既要想方案，又要写代码，还要自己测，容易顾不过来
没有明确验收环节时，看起来“做完了”，其实只是“说自己做完了”

所以长时间运行 AI，真正考验的往往不是模型单次输出能力，而是 任务拆分、状态衔接、角色分工和反馈回路。

02 Ralph 方案：把长任务拆成很多短回合

Ralph 的思路很适合先解决“上下文越跑越脏”这个问题。

它的核心做法是：

用循环不断启动新的 agent 会话
每轮只处理一个足够小的任务
把跨轮状态放到文件里，而不是全压在同一个对话上下文里

这样做的好处很直接：每次都是 fresh context，单轮会更聚焦，也更不容易被历史消息拖慢。

如果你已经看过 Ralph 相关项目，会发现这套方法背后的逻辑很一致：

当前任务写在结构化文件里
中间经验写到进度文件里
代码变化留在 git 历史里

换句话说，Ralph 不是试图让一个 Agent “永远记住所有事”，而是主动把记忆外置，让会话本身保持轻一点。

这类方案特别适合下面几种情况：

任务已经能拆成一组小 story
每个 story 都能在单个上下文窗口里完成
项目里已经有测试、typecheck 或其他检查机制

它解决的是“如何让 AI 一轮一轮稳定推进”。

03 多智能体方案：把一个人做不完的事分出去

另一条路线是多智能体协同。

从这类工作流设计思路来看，更值得推荐的通常是这种方式：主 Agent 不直接埋头干活，而是负责协调；子 Agent 各自处理开发、测试、检查、验收等不同任务。

这和 Ralph 的区别在于：

Ralph 更像串行迭代
多智能体更像并行分工

如果任务里天然有不同角色，多智能体会更顺手。比如：

一个 Agent 负责拆任务和写执行计划
一个 Agent 负责具体实现
一个 Agent 负责测试和验证
一个 Agent 负责回看结果是不是符合最初需求

这样做的价值不是“多开几个窗口显得很高级”，而是让不同工作职责分离开。原来塞在一个 Agent 身上的几件事，现在可以拆成几个更明确的环节。

一旦角色边界清楚，很多问题都会变轻：

写的人不必同时当审的人
跑测试的人不必重新推导整套需求
主 Agent 不会被实现细节淹没

它解决的是“如何让 AI 像一个小团队那样配合”。

04 真正关键的，不是多开，而是怎么拆

无论是 Ralph 还是多智能体，最容易被忽略的一点都是：流程设计比多开几个 Agent 更重要。

如果任务拆分不对，就算开再多 Agent，也只是把混乱并行化。

比较稳的拆法通常有几个特点：

一个任务只对应一个明确目标
一个角色只负责一类输出
每轮都有清楚的完成标准
上一轮的结果能被下一轮直接消费

比如比起给 AI 一个“把整个功能做完”的大指令，更稳的方式往往是：

先拆出需求和边界
再拆实现
再拆测试
最后单独做验收

这类拆法的好处是，问题一旦出现，更容易知道是出在理解、实现、测试，还是交付标准上。

05 为什么验收环节特别重要

很多 AI 工作流失败，不是因为前面完全没做事，而是因为最后缺了一个真正独立的确认动作。

在长任务里，“已经生成结果”和“结果真的可用”之间，经常隔着一整层差距。

这里有个很值得重视的方向，就是把开发和验收拆开看。哪怕不做到特别复杂，至少也应该把这些问题单独问一遍：

它真的完成了最初那条任务吗
有没有只改表面、没解决根因
测试是不是只验证了最顺利的路径
有没有把上游要求悄悄改掉

只要这层检查缺位，AI 很容易在长流程里不断“自我宣布成功”。

06 两条路线怎么选

如果只是想快速判断，可以先这么理解：

你最痛的是上下文膨胀和长会话失焦，先看 Ralph
你最痛的是一个 Agent 身兼多职、任务之间互相打架，先看多智能体

再具体一点：

Ralph 更适合流程清楚、任务细碎、可以按回合推进的工作
多智能体更适合角色明显、需要并行和交叉验证的工作

很多时候，这两条路也不是非此即彼。比较成熟的做法，反而可能是把它们组合起来：

外层用 Ralph 这种迭代循环推进大任务
内层在单轮里再用多智能体处理研究、实现、测试和验收

这样既能控制长上下文，又能提高单轮内部的协作效率。

07 一句话总结

这类方法最值得看的地方，不是单独推荐了 Ralph 或多智能体，而是把一个很现实的问题讲清楚了：让 AI 长时间稳定工作，关键从来不只是模型本身，而是你有没有把上下文、任务、角色和验收设计好。

如果你已经开始让 Claude Code、Codex 或其他 coding agent 处理更长的真实任务，这类工作流思路会比“再换一个更强模型”更值得优先补课。

Ralph 是什么：把 Claude Code 和 Amp 变成可循环执行的自主开发流程

Mon, 27 Apr 2026 08:08:55 +0800

如果你最近在关注 coding agent 的长流程执行，snarktank/ralph 是个很值得看一眼的小项目。它不是再做一个新的模型壳子，也不是再包一层聊天界面，而是把 Claude Code 或 Amp 组织成一个可以反复运行的 autonomous loop，让 AI 按 PRD 里的 story 一项一项往前做，直到全部完成。

它的核心思路其实很直接：不要让同一个 agent 在一个越来越长、越来越脏的上下文里硬撑，而是每轮都重新启动一个全新的 AI coding session。 这样做的好处是，上下文不会一路膨胀，任务边界也更清楚。

01 Ralph 是什么

Ralph 的官方定位很明确：它是一个 autonomous AI agent loop，会反复调用 AI coding tool，直到 PRD 里的项目都做完。

当前仓库支持两种工具：

Amp CLI
Claude Code

每一轮迭代都会启动一个 fresh instance。也就是说，不依赖“同一个会话一直聊下去”，而是依赖这些外部状态来保存记忆：

git 历史
progress.txt
prd.json

这点非常关键。很多人让 agent 跑长任务时，最大的痛点不是模型不会写，而是会话越跑越重，最后开始漏上下文、忘要求、反复返工。Ralph 的设计，基本就是冲着这个问题去的。

02 它怎么工作

Ralph 的工作流分成三步：

1. 先写 PRD

README 里建议先用配套的 prd skill 生成需求文档，把功能拆成比较细的 story。

2. 再把 PRD 转成 `prd.json`

然后用 ralph skill，把 Markdown 版 PRD 转成结构化的 prd.json。这个文件里会保存 user stories，以及每一项是不是已经通过。

3. 运行循环脚本

真正执行的是 ralph.sh。命令大致是：

1
2

./scripts/ralph/ralph.sh [max_iterations]
./scripts/ralph/ralph.sh --tool claude [max_iterations]

默认是 10 轮。每一轮大致会做这些事：

从 branchName 创建分支
选择优先级最高、passes: false 的 story
只实现这一项
跑质量检查，比如 typecheck 和 tests
检查通过后提交代码
更新 prd.json
把经验追加到 progress.txt
继续下一轮

也就是说，Ralph 并不追求“一口气把整件事做完”，而是把任务压缩成很多个能在单个上下文窗口里完成的小闭环。

03 Ralph 最有意思的地方

1. 每轮都是 fresh context

这是 Ralph 最核心的设计点。README 里强调，每次迭代都是一个新的 AI 实例，跨轮记忆只靠 git、progress.txt 和 prd.json。

这和很多人平时直接在一个长对话里让 Claude Code 或其他工具连续工作很不一样。后者在任务变大后，很容易被历史消息拖慢，还会逐渐失去焦点。Ralph 则是主动接受“单轮记不住全部”，然后把记忆放到外部文件里。

2. 强制把任务拆小

仓库文档特别强调，单个 PRD item 必须小到能在一个 context window 里完成。像“加一个筛选器”“改一个 server action”“补一列数据库字段”这种粒度比较合适；而“重构整个 API”“做完整 dashboard”这种就太大了。

这个约束其实很现实。很多 autonomous agent 跑崩，不是 loop 本身有问题，而是任务切分太粗，让模型一轮里就背了过量目标。

3. 不是只有代码，连经验也要沉淀

除了 progress.txt，README 还特别强调要更新 AGENTS.md。原因也很实际：未来迭代和未来开发者都会读这些说明，所以每轮发现的模式、坑点、约定，最好都落到项目文档里。

换句话说，Ralph 不只是让 agent 连续写代码，也想让它连续积累对代码库的工作记忆。

04 它适合什么场景

如果你的任务具备这些特征，Ralph 会比较对路：

已经能拆成一组明确的 user stories
代码库里有比较可靠的反馈回路，比如测试、typecheck、CI
你希望 agent 持续推进，但不想把所有事压在单个长对话里
你接受它按迭代方式一点点完成，而不是一次性全做完

反过来说，如果你的需求还很模糊，或者任务本身高度依赖来回讨论、频繁改方向，那 Ralph 可能还不是第一选择。它更适合“需求已经整理好，现在需要稳定推进执行”的阶段。

05 它和普通 Claude Code 用法有什么不同

如果平时直接用 Claude Code，常见模式是你开一个会话，让它持续读代码、改代码、跑命令。这个方式在中小任务上很好用，但在大任务上容易碰到两个问题：

上下文越来越长
中间决策不容易结构化沉淀

Ralph 的做法更像把 Claude Code 或 Amp 变成一个“批处理执行器”：

任务来源不是临时聊天，而是 prd.json
每轮只认一个 story
完成状态写回文件
经验写进 progress.txt
代码提交进 git

所以它更像是“给 coding agent 加了一层迭代控制器”，而不是换了一个新的 AI assistant。

06 一个值得注意的前提

Ralph 能不能跑顺，关键不在 loop 本身，而在反馈回路够不够好。README 里写得很直白：如果没有 typecheck、tests、CI 这些机制，错误会在后续迭代里不断累积。

对于前端任务，仓库甚至明确建议把“用浏览器验证”写进 acceptance criteria。因为如果没有实际验证，agent 很容易把“看起来写完了”和“真的可用”混在一起。

这点很重要。Ralph 不是 magical automation，它更像把你现有的工程纪律放大。如果你的项目本来就有清晰任务拆分和可靠检查，它会更有价值；如果这些基础还没有，loop 只会把混乱重复很多次。

07 一句话总结

Ralph 最值得看的地方，不是它写了多少新基础设施，而是它把一个朴素但很有用的思路落成了现成流程：让 Claude Code 或 Amp 每轮只做一个足够小的 story，用 fresh context 保持专注，再靠 git、prd.json 和 progress.txt 维持跨轮连续性。

如果你已经开始把 coding agent 用到真实项目里，并且正在被“长任务怎么稳定推进”这个问题困住，Ralph 这套方法很值得参考。

参考链接

GitHub 仓库：https://github.com/snarktank/ralph
交互式流程图：https://snarktank.github.io

nuwa-skill：把“蒸馏一个人”从灵感变成可执行流程

Wed, 22 Apr 2026 16:20:00 +0800

[alchaincyf/nuwa-skill](https://github.com/alchaincyf/nuwa-skill) 很容易让人先想到一句话：让 AI 模仿名人的口吻回答问题。但它真正有意思的地方，不在“像不像”，而在于它试图把“蒸馏一个人的思维方式”做成一条可重复执行的流程。

这件事一旦成立，价值就不只是做几个好玩的角色 prompt，而是把某个人的判断框架、关注重点、常见启发式和表达习惯，沉淀成一个可以反复调用的 skill。你要的不是一句像某某说出来的话，而是一个更接近“如果他来分析这件事，会先看哪里、怎么取舍、会质疑什么”的工作接口。

它解决的不是“模仿”，而是“建模”

很多所谓的人物 prompt，本质上只是风格贴皮。

它们通常会要求模型：

用某个人的语气说话
多引用这个人的经典句式
尽量模仿他公开表达里的措辞

这样做在演示里很抓眼球，但一到真实任务就很容易露馅。原因也很简单：语气是表层，判断结构才是核心。一个人物之所以有辨识度，不是因为他爱说哪几个词，而是因为他在面对问题时，总会用某些稳定的方法切入。

nuwa-skill 的方向更像是把这种“稳定的方法”提取出来。换句话说，它关心的不是“怎么说得像”，而是“怎么想得像”。

一个更完整的工作流

从仓库说明来看，nuwa-skill 想做的是一套端到端流程：输入一个人名，然后自动完成调研、提炼、验证，再把结果组织成能在 Claude Code 里调用的 skill。

这背后有几个很关键的变化。

第一，它默认蒸馏对象可以不是你团队里的同事。很多人第一次接触这类能力，会先想到“把优秀同事的方法论沉淀下来”。这当然有价值，但边界也很明显：可学习样本有限，而且往往只覆盖团队内部经验。nuwa-skill 直接把对象扩展到更广的人群，比如创业者、投资人、科学家、产品经理、写作者。

第二，它强调的是“自动完成”，而不是让用户手工拼 prompt。真正让这类能力能落地的，不是 prompt 文案写得多华丽，而是你能不能稳定完成资料搜集、观点归纳、模式抽取和结果校验。只要其中某一步完全依赖手工，复用成本就会快速上升。

第三，它试图把产物变成一个 skill，而不是一段一次性对话。前者可以被多次调用、组合、迭代；后者往往只在当前上下文里有效，过几轮就散了。

为什么这种方向值得关注

如果把 AI 当成问答机，最自然的用法是“给我一个答案”。但如果把 AI 当成工作台，问题就会变成“给我一个看问题的方法”。

nuwa-skill 的价值，更偏向后者。

比如你面对一个产品决策，想要的未必是一个标准答案，而是几种截然不同的分析框架：

有人会先看长期复利
有人会先看资源约束
有人会先看用户体验的一致性
有人会先看市场进入时机

如果这些框架能被稳定封装出来，AI 的角色就会从“替你写一段话”变成“帮你快速切换视角”。这比单纯模仿名人语录有用得多，因为它直接作用在决策质量上。

它最打动人的地方：把隐性知识变成可调用资产

很多高价值能力本来就很难写成 SOP。

一个人为什么判断比别人准，往往不是因为他掌握了更多显性规则，而是因为他在长期实践里形成了一套隐性的筛选机制：

什么信号值得优先关注
什么噪音应该直接忽略
哪些问题要拆开看
哪些问题要反过来问
哪些结论必须等待更多证据

这类能力平时很难沉淀，因为它不总能被本人完整说清楚。也正因为如此，一旦能被结构化提取，价值会很高。nuwa-skill 吸引人的地方就在这里：它想处理的不是表面知识搬运，而是认知习惯的再组织。

适合什么场景

我觉得这类 skill 最适合以下几种场景。

1. 决策前的多视角审视

当你已经有一个方案，但担心自己只是在顺着熟悉的路径思考时，切换到不同“人物视角”去审视同一问题，会比让模型继续顺着你的原话扩写更有价值。

2. 学习某类高手的判断框架

很多人学习高手，习惯收藏语录、看访谈、抄摘要，但最后往往只记住了几句漂亮话。把思维模式做成 skill 之后，学习方式会更接近“带着问题反复调用”，而不是“做一堆静态摘抄”。

3. 让团队共享一种分析方式

团队里真正稀缺的，不只是知识文档，而是“我们遇到问题时通常怎样想”。如果未来这套流程成熟，它也可以反过来用于沉淀组织内部高手的方法论，只是它显然不打算把这个能力局限在组织内部。

这类项目真正难的地方

当然，方向有吸引力，不代表问题已经解决。

这类项目最难的，从来不是安装一个 skill，而是下面几件事：

资料源是否足够可靠
提炼出的模式是不是稳定，而不是偶然语料带来的错觉
模型是在使用人物框架分析，还是只是在复述常见印象
不同人物之间的边界会不会被模型自动抹平

也就是说，最关键的不是“能不能生成一段像样的话”，而是“这个 skill 产出的认知框架是否经得起多任务复用”。如果未来它在验证环节继续做深，这类项目的可信度会明显提高。

为什么它比“提示词模板库”更进一步

过去不少项目会把这类能力做成模板库：一个人物对应一段 prompt，用户复制进去就用。问题是模板库本质上还是静态资产，更新慢、验证弱，而且很难形成完整的生产流程。

nuwa-skill 更进一步的地方，是它把“人物蒸馏”从一个模板问题，推进成一个流程问题。

一旦工作重心从“写一段 prompt”转到“如何系统生成、校验、迭代一个人物 skill”，这件事就更像工程，而不是灵感。对真正想长期使用的人来说，后者显然更重要。

结语

nuwa-skill 有意思，不是因为它把 AI 变成了名人模仿秀，而是因为它把“如何学习一个人的思考方式”这件事，往可执行、可复用、可迭代的方向推进了一步。

如果说很多人物 prompt 解决的是“像谁说话”，那它想解决的，是“像谁那样看问题”。前者适合演示，后者才更接近生产力工具。

参考链接

GitHub 仓库：https://github.com/alchaincyf/nuwa-skill
项目说明：https://github.com/alchaincyf/nuwa-skill/blob/main/README.md
Skill 定义：https://github.com/alchaincyf/nuwa-skill/blob/main/SKILL.md

RAGFlow 项目整理：开源 RAG 引擎的功能与使用方法

Wed, 15 Apr 2026 22:09:25 +0800

RAGFlow 是 infiniflow 开源的 RAG（Retrieval-Augmented Generation，检索增强生成）引擎。它的目标不是只做一个“上传文件然后问答”的知识库外壳，而是把文档解析、切分、检索、重排、引用溯源、模型配置、Agent 能力和 API 集成放进一套完整工作流里。

如果你正在做企业知识库、文档问答、客服助手、内部资料检索，或者想给 LLM 加一层更可靠的上下文来源，RAGFlow 属于值得重点看的开源方案。

01 RAGFlow 解决什么问题

普通 RAG 系统最容易遇到的问题有三个：

文档解析质量不稳定，尤其是 PDF、扫描件、表格、图片、复杂排版文档。
切分策略不透明，命中结果看起来像“搜到了”，但上下文并不完整。
回答缺少可靠引用，用户很难判断答案来自哪里。

RAGFlow 的重点正好放在这些地方。项目 README 里强调了 Deep document understanding、模板化切分、可视化 chunk、引用溯源和多路召回加重排。换句话说，它更关注“高质量数据进入，高质量答案出来”，而不是只把向量数据库和聊天框接起来。

02 核心功能

1. 深度文档理解

RAGFlow 支持从复杂格式的非结构化数据中抽取知识。README 中列出的数据类型包括 Word、PPT、Excel、TXT、图片、扫描件、结构化数据、网页等。

这对企业知识库很关键。真实资料通常不是干净的 Markdown，而是合同、报告、表格、扫描 PDF、产品手册、截图和网页混在一起。如果解析质量不够，后面的向量检索和 LLM 回答都会被拖垮。

2. 模板化切分

RAGFlow 提供模板化 chunking。它的价值在于：切分策略不是黑盒，可以根据文档类型选择更合适的方式。

例如普通文章、论文、表格、问答文档、图片说明、合同条款，对 chunk 的粒度和边界要求都不一样。模板化切分可以减少“句子被切碎”“表格上下文丢失”“标题和正文分离”这类问题。

3. 可追溯引用

RAGFlow 强调 grounded citations，也就是回答要能追溯到来源片段。它还提供 chunk 可视化，方便人工干预解析和切分结果。

这点对生产环境尤其重要。企业内部问答不是只要“看起来像答案”，还要能查证来源。对于政策、合规、财务、技术文档、客户支持资料来说，引用和溯源几乎是刚需。

4. 自动化 RAG 工作流

RAGFlow 把 RAG 流程做成相对完整的链路：

创建知识库
上传或同步数据
解析文档
查看和干预 chunk
配置 LLM 与 embedding 模型
执行多路召回与重排
构建聊天助手
通过 API 集成到业务系统

这让它更像一个 RAG 平台，而不是一个单点库。对于团队来说，UI、可视化和 API 都有价值：非研发人员可以维护知识库，研发人员可以把能力接入已有系统。

5. Agent、MCP 与工作流能力

RAGFlow 的近期更新里已经包含 Agentic workflow、MCP、Agent Memory、代码执行组件等内容。这说明它不只想做传统知识库问答，也在向 Agent 场景延伸。

典型方向是：Agent 在执行任务时，可以把 RAGFlow 作为可靠的企业知识上下文层；需要查资料时从知识库召回，生成回答时保留引用，必要时再组合工具调用或工作流。

03 基本使用流程

按照官方快速开始文档，RAGFlow 的常见使用路径可以概括为下面几步。

1. 准备运行环境

官方 README 给出的基础要求是：

CPU >= 4 cores
RAM >= 16 GB
Disk >= 50 GB
Docker >= 24.0.0
Docker Compose >= v2.26.1

如果要使用代码执行器的沙箱功能，还需要 gVisor。另外要注意，官方 Docker 镜像主要面向 x86 平台；如果是 ARM64，需要按官方说明自行构建镜像。

2. 拉取项目

1
2

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker

3. 检查 `vm.max_map_count`

RAGFlow 部署会依赖 Elasticsearch / OpenSearch 这类组件，因此 Linux 上通常需要确认：

`1`	`sysctl vm.max_map_count`

如果数值低于 262144，可以临时设置：

`1`	`sudo sysctl -w vm.max_map_count=262144`

如果希望重启后仍然生效，需要写入 /etc/sysctl.conf。

4. 使用 Docker Compose 启动

CPU 模式可以直接启动：

`1`	`docker compose -f docker-compose.yml up -d`

如果要用 GPU 加速 DeepDoc 任务，README 中给出的方式是在 .env 中启用 DEVICE=gpu 后再启动：

1
2

sed -i '1i DEVICE=gpu' .env
docker compose -f docker-compose.yml up -d

启动后查看日志：

`1`	`docker logs -f docker-ragflow-cpu-1`

看到服务启动完成后，再通过浏览器访问服务器地址。默认配置下，通常可以直接访问：

`1`	`http://IP_OF_YOUR_MACHINE`

5. 配置模型 API Key

RAGFlow 需要配置 LLM 和 embedding 模型。README 提到可以在 service_conf.yaml.template 中选择默认 LLM factory，并更新对应的 API_KEY。

实际使用时，你需要根据自己的模型供应商配置：

聊天模型
embedding 模型
rerank 模型
多模态模型（如果要理解 PDF / DOCX 中的图片）

6. 创建知识库并上传文档

服务启动后，典型操作是：

登录 Web UI。
创建 dataset / knowledge base。
上传文档或配置数据源同步。
等待解析完成。
查看 chunk 结果，必要时人工调整。
创建聊天助手，选择知识库。
测试问答效果和引用来源。

如果要接入业务系统，可以继续使用 RAGFlow 的 API 或 SDK，把知识库检索和聊天能力接到自己的应用里。

04 适合哪些场景

RAGFlow 适合这些需求：

企业内部知识库问答
产品手册、技术文档、FAQ 检索
客服助手和售前支持助手
合同、报告、制度文件的可追溯问答
多格式资料统一整理
需要 UI 维护知识库，同时又要 API 集成的团队
想把 RAG 能力作为 Agent 上下文层的系统

它尤其适合文档格式复杂、需要引用溯源、希望人工干预解析结果的场景。

05 使用时要注意什么

第一，RAGFlow 不是轻量脚本。它对机器资源有要求，官方建议至少 4 核 CPU、16GB 内存和 50GB 磁盘。如果只是给少量 Markdown 做问答，可能没必要上这么完整的平台。

第二，文档质量仍然重要。RAGFlow 能改善解析和切分，但不能让低质量、过期、互相矛盾的资料自动变得可靠。真正上线前，知识库治理仍然要做。

第三，模型配置会直接影响效果。embedding、rerank、聊天模型、多模态模型的选择，都会影响召回和回答质量。RAGFlow 提供了工作流，但效果仍然要靠数据、模型和参数一起调。

第四，生产环境要关注权限和数据安全。企业知识库里往往有内部资料，部署方式、访问控制、日志、API Key、模型供应商数据策略都要提前设计。

06 简短判断

RAGFlow 的优势在于把 RAG 里最麻烦的部分做成了平台化能力：复杂文档解析、可解释切分、引用溯源、多路召回、重排、模型配置、Web UI、API 和 Agent 扩展。

如果你要做的是可验证、可维护、可接入业务系统的企业知识库，RAGFlow 比“向量库 + 简单聊天 UI”的方案更完整。反过来，如果只是个人小规模资料问答，或者数据格式非常简单，轻量 RAG 框架可能更省资源。

Firecrawl 项目整理：给 AI Agent 用的网页搜索、抓取与交互 API

Wed, 15 Apr 2026 13:45:03 +0800

Firecrawl 的定位很明确：把网页变成 AI Agent 更容易消费的数据。它不是单纯的爬虫脚本，而是把搜索、单页抓取、整站遍历、页面交互、结构化抽取和 Agent 工作流封装成 API，让模型或自动化系统少处理网页里的噪声。

01 它解决什么问题

很多 AI 应用需要读网页，但真实网页并不友好：页面有 JavaScript 渲染、弹窗、分页、登录态、反爬限制、PDF 或 DOCX 等非 HTML 内容，还有大量和正文无关的导航、广告、脚本和样式。

Firecrawl 想解决的是中间层问题：应用只提出“我要这个页面/这个站点/这个主题的数据”，它负责把网页打开、抓取、清洗，再输出成更适合 LLM 使用的 Markdown、HTML、截图或 JSON。

这类工具的价值不在于“能不能请求一个 URL”，而在于能不能稳定地把复杂网页处理成可用数据。对于 RAG、AI 搜索、竞品调研、自动化资料收集、网页内容监控来说，这一层很容易成为工程里的脏活。

02 核心功能

Firecrawl README 里把能力分成几类：

Search：搜索网页，并返回结果页的完整内容。
Scrape：把单个 URL 转换成 Markdown、HTML、截图或结构化 JSON。
Interact：先抓取页面，再通过提示词或代码执行点击、滚动、输入、等待等操作。
Agent：直接描述你要找什么，由 Agent 自动搜索、导航并返回结果。
Crawl：抓取一个网站下的多页内容。
Map：快速发现一个网站中的 URL。
Batch Scrape：异步批量抓取大量 URL。

如果只看名字，它像是“爬虫服务”。但从功能组合看，它更接近 AI 应用的数据入口：搜索负责发现，抓取负责清洗，交互负责处理动态页面，Agent 负责把“找资料”这件事进一步自动化。

03 为什么适合 AI Agent

传统爬虫通常假设你已经知道 URL，也知道页面结构。但 Agent 场景经常不是这样：用户只会问一个任务，比如“找出某家公司最新价格页里的套餐差异”，系统需要自己搜索、打开页面、比较内容，再把来源带回来。

Firecrawl 的 Agent 接口正是为这类任务设计的。它可以只接收自然语言提示，也可以限制在指定 URL 范围内工作；如果需要结构化结果，还可以配合 schema 输出固定字段。

这对应用层有两个好处：

不必为每个网站单独写解析器。
返回结果更容易进入 LLM、数据库或后续自动化流程。

当然，这并不意味着它能替代所有定制爬虫。对于强约束、高频、大规模、字段非常稳定的抓取任务，专门写解析逻辑仍然可能更便宜、更可控。Firecrawl 更适合网页来源多、页面结构变化大、需要快速接入 AI 工作流的场景。

04 MCP、CLI 与集成

Firecrawl 也明显在向 Agent 工具链靠拢。README 中提供了 MCP Server 的接入方式，也提供了面向 AI coding agent 的 Skill/CLI 初始化命令。

这说明它不只是给后端服务调用，也希望直接进入 Claude Code、OpenCode、Antigravity、MCP 客户端等工作流。对于经常让 Agent 查资料、抓网页、整理内容的人来说，这种集成方式比手写 API 调用更轻。

它还列出了 Zapier、n8n、Lovable 等平台集成。这个方向很实用：网页数据不一定只进代码，也可能进入自动化表格、低代码流程、内容生产系统或内部知识库。

05 开源、自托管与许可边界

Firecrawl 是开源项目，主仓库以 AGPL-3.0 为主；README 也说明 SDK 和部分 UI 组件使用 MIT 许可，具体要看对应目录里的 LICENSE 文件。

这点需要注意：如果只是使用它的云服务，主要关心 API 成本、稳定性和合规边界；如果准备自托管并对外提供服务，AGPL-3.0 的义务就需要认真评估。

README 还提醒用户要尊重网站政策、隐私政策和使用条款，并说明默认会遵守 robots.txt。这类工具越强，越需要把合规和抓取边界写进系统设计里，而不是等上线后再补。

06 适合哪些场景

我会把 Firecrawl 放在这些场景里优先考虑：

给 RAG 系统抓取网页资料，并希望直接得到干净 Markdown。
做 AI 搜索或研究助手，需要搜索后读取完整页面。
抓取 JavaScript 较重的网站，不想自己维护浏览器集群。
做竞品、价格、文档、新闻、招聘页等公开信息监控。
给 MCP 客户端或 AI coding agent 增加实时网页读取能力。
需要快速验证一个网页数据产品，而不是先搭一套爬虫基础设施。

不太适合的情况也很清楚：

目标网站字段极少、结构稳定，用简单脚本就能完成。
抓取量巨大，成本比开发维护成本更敏感。
业务对数据来源、重试策略、反爬行为和审计要求非常细。
许可或合规要求不允许引入 AGPL 组件或外部云服务。

07 简短判断

Firecrawl 的核心价值，是把“网页到 AI 可用数据”这段麻烦流程产品化。它把搜索、抓取、清洗、交互、批处理和 Agent 式资料收集放在同一套接口里，对 AI 应用开发者很省心。

如果你的项目经常需要让模型读取真实网页，尤其是页面来源分散、结构不稳定、还要接入 MCP 或 Agent 工作流，Firecrawl 值得放进工具箱。反过来，如果任务只是固定网站的低成本批量采集，传统爬虫或专用解析器仍然更合适。

OpenHarness 是什么：这个开源 Agent Harness 能做什么

Sun, 12 Apr 2026 23:45:00 +0800

如果你最近在关注开源 AI Agent 工具，HKUDS/OpenHarness 是一个很值得留意的新项目。它不是单纯再做一个“会聊天的外壳”，而是把一个可运行、可扩展、可治理的 Agent 基础设施单独抽出来，做成了一个开源的 Agent Harness。

按照官方 README 的说法，OpenHarness 主要提供的是一整套轻量级 Agent 基础能力，包括工具调用、技能加载、记忆机制、权限治理和多 Agent 协调；而它附带的 ohmo，则是建立在这套基础设施之上的个人 AI 助手应用。

01 OpenHarness 是什么

可以把 OpenHarness 理解成“给大模型装上手脚、记忆和边界”的运行层。

大模型本身擅长推理和生成，但如果你想让它真正成为一个可以长期工作的 Agent，通常还需要这些外围能力：

调工具，而不是只输出文字
读写文件、执行命令、访问搜索和网页能力
在长会话里保留上下文和记忆
对危险操作做权限控制
把大任务拆给多个子 Agent 并行处理

OpenHarness 的目标，就是把这部分“围绕模型的工程层”做成一个清晰、开源、可检查的 Python 实现。它更像一个 Agent 操作底座，而不是单独强调某一种模型或某一个聊天界面。

02 这个项目的基本功能

从当前 GitHub 首页和 README 来看，OpenHarness 的核心能力主要集中在下面几块。

1. Agent Loop

这是 Agent 能连续工作的核心执行循环。官方列出的重点包括：

流式工具调用循环
API 重试和指数退避
并行工具执行
Token 统计和成本追踪

这部分的意义在于，Agent 不只是“一问一答”，而是可以在一次任务里连续观察、思考、调用工具、读取结果、再继续下一步。

2. 工具、Skills 和插件体系

OpenHarness 把工具层做得比较完整。项目主页提到它已经内置了文件、Shell、搜索、网页、MCP 等多类工具，并支持按需加载 Markdown 技能文件。

它的价值不只是“工具多”，更重要的是组合方式比较开放：

可以直接使用内置工具
可以按任务加载 skills
可以通过插件扩展 hooks、skills 和 agents
兼容 anthropics/skills 与相关插件生态

如果你希望把某些固定流程沉淀成可复用能力，而不是每次都靠 prompt 临时描述，这一层会很有用。

3. 上下文与记忆

这部分是 OpenHarness 很重要的差异点。官方给出的关键词包括：

CLAUDE.md 发现与注入
自动上下文压缩
MEMORY.md 持久记忆
会话恢复与历史延续

这意味着它不只是处理当前这一轮输入，而是会尽量把“项目约定”“历史任务”“长期偏好”保留下来，让 Agent 更适合持续工作，而不是每次从零开始。

4. 权限治理与安全边界

Agent 真正进入文件系统、终端和网络之后，治理就非常关键。OpenHarness 在这部分提供了：

多级权限模式
基于路径和命令的规则控制
PreToolUse / PostToolUse hooks
交互式审批弹窗

简单说，它不只是让 Agent “能做事”，也考虑了“哪些事能直接做，哪些事必须先经过确认”。

5. 多 Agent 协调

OpenHarness 还支持把任务拆给子 Agent 处理。当前公开资料里提到的能力包括：

子 Agent 创建与委派
团队注册与任务管理
后台任务生命周期管理

对复杂任务来说，这意味着它可以不只靠一个 Agent 串行推进，而是尝试做并行协作。

6. 多 Provider 工作流

OpenHarness 当前并不把 provider 只当成一个底层 API 名称，而是抽象成 workflow + profile。根据 README，当前支持的方向包括：

Claude / Anthropic-compatible
OpenAI-compatible
Codex Subscription
GitHub Copilot
Moonshot(Kimi)、GLM、MiniMax 等兼容后端

这让它更像一个“多模型、多入口”的 Agent 运行框架，而不是绑定某一家服务商。

7. React TUI 与非交互模式

OpenHarness 自带终端交互界面，运行 oh 后可以进入 React/Ink TUI。官方 README 提到它支持：

命令选择器
权限确认
模型切换
Provider 切换
会话恢复

如果你不想进入交互界面，也可以用非交互模式直接执行单次任务，例如把结果输出到标准输出、JSON 或流式 JSON，适合脚本化和自动化场景。

03 `ohmo` 是什么

如果说 OpenHarness 是底层基础设施，ohmo 就是建立在这套基础设施之上的“个人 Agent 应用”。

项目首页对 ohmo 的定位很明确：它不是普通聊天机器人，而是一个可以在长会话里持续工作的个人助手。官方描述里提到，它可以在 Feishu、Slack、Telegram、Discord 等渠道里与你交互，并执行诸如：

fork 分支
写代码
跑测试
发起 PR

另外，README 还特别强调：ohmo 可以运行在你现有的 Claude Code 或 Codex 订阅之上，不一定要求额外申请新的 API key。对已经在使用这些订阅工具的人来说，这一点门槛比较低。

04 它适合什么场景

从这个项目当前公开出来的能力看，OpenHarness 比较适合下面几类人：

想研究生产级 Agent 到底由哪些基础模块组成
想自己搭建一个可扩展的开源 Agent 运行层
想把工具、技能、记忆、权限、多 Agent 协调放到同一个框架里
不希望被单一模型厂商或单一客户端形态绑定
想基于现成架构继续做垂直领域 Agent 或个人助手

如果你的目标只是“找一个能直接聊天的成品助手”，那 OpenHarness 本体可能不是最轻量的选择；但如果你更关心 Agent 基础设施、工程可控性和后续扩展，这个项目就很值得研究。

05 快速理解它的定位

一句话总结：

OpenHarness 负责把大模型变成真正可执行任务的 Agent，ohmo 负责把这套能力包装成一个可以长期陪你工作的个人助手。

也可以把它拆成两层来看：

OpenHarness：开源 Agent Harness，本质是基础设施
ohmo：基于这套基础设施构建的 personal-agent app

截至 2026 年 4 月 12 日，项目 GitHub 首页显示它的更新已经推进到 v0.1.6（2026 年 4 月 10 日），重点继续放在自动上下文压缩、MCP 传输能力、React TUI 和多 Agent 运行稳定性上。这说明它目前仍处于快速演进阶段，但方向已经非常清晰。

参考链接

GitHub 项目主页：https://github.com/HKUDS/OpenHarness
英文 README：https://github.com/HKUDS/OpenHarness/blob/main/README.md
中文 README：https://github.com/HKUDS/OpenHarness/blob/main/README.zh-CN.md

Playwright CLI 使用入门：安装、Skills、会话管理与常用命令

Sun, 12 Apr 2026 14:36:58 +0800

如果你最近在用 Claude Code、GitHub Copilot 或其他 coding agent 做浏览器自动化，microsoft/playwright-cli 是一个很值得关注的新工具。它不是传统意义上那个“给人手动敲命令用”的浏览器小工具，而是一个面向 coding agent 的 Playwright CLI，强调的是更低 token 开销、更轻量的命令接口，以及和 Skills 工作流的结合。

从官方 README 来看，Playwright CLI 的核心思路很明确：相比 MCP 把大量工具 schema 和页面结构塞进模型上下文，CLI 命令方式更紧凑，更适合在大代码库、测试任务和浏览器自动化之间来回切换的 agent 工作流。

01 Playwright CLI 是什么

playwright-cli 是微软开源的一个 Playwright 命令行工具，官方描述是 “CLI for common Playwright actions”。它主要用来完成这些事情：

打开页面并驱动浏览器
记录和生成 Playwright 代码
抓取页面快照，获取元素引用
截图、导出 PDF
配合 coding agent 进行自动化测试和网页操作

当前 GitHub README 里把它定位得非常明确：如果你正在使用 coding agents，CLI 往往比 Playwright MCP 更合适；如果你更需要持久状态、丰富 introspection 和长时间 agentic loop，MCP 仍然有它的价值。

换句话说，Playwright CLI 更像“给 AI 编码助手准备的浏览器自动化接口”，而不只是给人类工程师手动点击网页的工具。

02 它的优点在哪里

1. 更适合 agent 工作流

官方 README 把第一优点直接写成了 Token-efficient。它不会强制把整页数据都塞进 LLM 上下文，而是通过更短、更专用的命令让 agent 操作浏览器。

这对 coding agent 很重要。因为在真实项目里，agent 不只是跑浏览器，还要看代码、改文件、跑测试、读日志。如果浏览器工具本身就很“吃上下文”，整体效率会明显下降。

2. 能和 Skills 一起工作

README 里专门强调了 playwright-cli install --skills。这说明官方不是把它当单纯的 shell 工具来做，而是把它设计成可以被 Claude Code、GitHub Copilot 等 agent 直接消费的技能入口。

如果你的工作流本身就建立在 Skills 之上，那 Playwright CLI 的接入会更自然。

3. 会话管理做得比较完整

Playwright CLI 支持 session。默认情况下，浏览器 profile 保存在内存里，同一个 session 里的 cookies 和 storage 会在多次 CLI 调用之间保留；如果加上 --persistent，还可以把 profile 落到磁盘，跨浏览器重启继续使用。

这让它比“一条命令打开浏览器，跑完就丢”的玩具型工具更实用，也更适合持续调试和 agent 长流程执行。

4. 自带可视化监控面板

README 里提供了 playwright-cli show，用于打开一个 dashboard，观察和控制所有运行中的浏览器 session。对于 agent 在后台跑自动化任务的场景，这一点很有价值，因为你可以随时接管、观察、排错，而不是只能盲跑。

03 安装与环境要求

根据当前 GitHub README，Playwright CLI 的基本要求是：

Node.js 18 或更高版本
Claude Code、GitHub Copilot 或其他 coding agent

安装命令如下：

1
2

npm install -g @playwright/cli@latest
playwright-cli --help

这里有个很容易踩坑的地方要特别注意：

官方当前推荐安装的是 @playwright/cli
不要把它和 npm 上历史遗留、已废弃的旧包 playwright-cli 混为一谈

也就是说，真正应该装的是 scoped package，而不是旧时代的同名历史包。

04 如何开始用

1. 安装 skills

如果你希望让 coding agent 直接使用 Playwright CLI，官方建议先安装 skills：

`1`	`playwright-cli install --skills`

README 里明确写到，Claude Code、GitHub Copilot 等工具会使用本地安装的 skills。

2. 直接让 agent 调用 CLI

如果你不想先处理 skills，也可以直接让 agent 读取 CLI 帮助信息：

1
2

Test the "add todo" flow on https://demo.playwright.dev/todomvc using playwright-cli.
Check playwright-cli --help for available commands.

官方把这种方式叫做 “Skills-less operation”。意思是即使不预先装 skill，也可以通过 CLI 自描述能力来驱动 agent。

3. 手动体验一遍最小流程

README 里给了一组很适合上手的 TodoMVC 示例：

playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli type "Water flowers"
playwright-cli press Enter
playwright-cli check e21
playwright-cli check e35
playwright-cli screenshot

这组命令的价值在于，它能让你很快理解 Playwright CLI 的交互方式：

open 负责打开页面
type 和 press 负责输入
check 用元素引用操作复选框
screenshot 保存结果

05 `--headed`、session 和监控面板

`--headed`

Playwright CLI 默认是 headless 的。如果你想直接看到浏览器窗口，需要在 open 时显式加上 --headed：

`1`	`playwright-cli open https://playwright.dev --headed`

这对于调试选择器、登录流程、验证码前后的交互观察会更方便。

session

官方 README 里强调了 session 的用法。你可以用不同 session 把不同项目或网站隔离开来：

1
2
3

playwright-cli open https://playwright.dev
playwright-cli -s=example open https://example.com --persistent
playwright-cli list

如果你是让 agent 长时间工作，还可以直接给它指定环境变量：

`1`	`PLAYWRIGHT_CLI_SESSION=todo-app claude .`

常用的 session 管理命令包括：

1
2
3

playwright-cli list
playwright-cli close-all
playwright-cli kill-all

其中：

list 用来列出所有 session
close-all 用来正常关闭所有浏览器
kill-all 用来强制杀掉所有浏览器进程

监控面板

如果你想看 agent 当前到底在浏览器里做了什么，可以运行：

`1`	`playwright-cli show`

按照 README 的说明，这个 dashboard 主要有两种视图：

Session grid：按 workspace 查看所有活动 session，带实时画面、URL 和页面标题
Session detail：查看单个 session 的实时界面，还能接管鼠标和键盘

这让 Playwright CLI 不只是“命令行可用”，而是具备了比较成熟的可观测性。

06 常用命令先记住哪些

如果你第一次接触 Playwright CLI，不需要一开始就把所有命令背下来。先记下面这些最核心的就够了：

页面与交互

playwright-cli open [url]
playwright-cli goto <url>
playwright-cli click <ref>
playwright-cli fill <ref> <text>
playwright-cli type <text>
playwright-cli hover <ref>
playwright-cli press <key>

获取页面结构

playwright-cli snapshot
playwright-cli snapshot <ref>
playwright-cli snapshot --depth=N
playwright-cli eval <func> [ref]

snapshot 很关键，因为很多后续操作都依赖元素引用 ref。你通常会先抓一次快照，再用返回的元素编号去点、填、勾选或截图。

输出结果

1
2

playwright-cli screenshot
playwright-cli pdf

标签页

playwright-cli tab-list
playwright-cli tab-new [url]
playwright-cli tab-close [index]
playwright-cli tab-select <index>

07 它适合谁

如果你属于下面这些场景，Playwright CLI 会很值得试：

你在用 Claude Code、Copilot 或其他 coding agent 做 E2E 测试
你希望浏览器自动化接口更轻量，不想把大量页面结构塞进上下文
你希望同一个浏览器 session 能跨多次命令持续存在
你想在 agent 自动跑网页任务时，随时打开监控面板观察进度

如果你的工作重点是“浏览器自动化如何与 coding agent 高效配合”，Playwright CLI 很可能会比传统的人类手动调试方式更顺手。

参考链接

Hermes Agent 是什么：简介、优点、快速上手与 OpenClaw 对比

Sun, 12 Apr 2026 14:07:58 +0800

如果你最近在关注开源 AI Agent，Hermes Agent 是一个很值得看一眼的新项目。它由 Nous Research 推出，核心卖点不是“再做一个聊天壳子”，而是把长期记忆、技能沉淀、上下文文件、MCP 扩展、消息网关和子代理并行这些能力，尽量收敛进一个统一的 agent 运行环境里。

从官方 README 的表述看，Hermes Agent 的目标很明确：它既可以像本地 CLI 助手一样在终端里工作，也可以像一个常驻云端的个人助理一样，通过 Telegram、Discord、Slack、WhatsApp、Signal 等渠道和你持续对话。对于希望把“代码助手”“自动化助手”“个人 AI 工作台”合并到一个系统里的用户来说，这个定位是很有吸引力的。

01 Hermes Agent 简介

Hermes Agent 是 Nous Research 开源的自改进型 AI Agent。它支持多种模型提供方，包括 Nous Portal、OpenRouter、OpenAI 以及自定义兼容 OpenAI 的端点；也支持在本地终端、Docker、SSH、Daytona、Modal 等不同执行后端上运行。

它和很多“会调用工具的聊天机器人”最大的区别在于，Hermes 不是只强调一次会话里的工具调用，而是强调跨会话的持续能力建设。官方文档里把这种思路拆成几块：

持久记忆：通过 MEMORY.md 和 USER.md 保存关于环境、项目、用户偏好的关键信息。
技能系统：把复杂任务里学到的流程沉淀成技能，后续按需加载。
上下文文件：自动读取 AGENTS.md、SOUL.md、.cursorrules 等文件，把项目约定直接注入会话。
MCP 集成：可以接入任何兼容 MCP 的工具服务器，扩展数据库、GitHub、文件系统、抓取等能力。
消息网关：除了 CLI，还能通过 Telegram、Discord、Slack、WhatsApp、Signal、Email 等入口使用。

如果只用一句话概括，Hermes Agent 更像是一个“带记忆、带技能、可扩展、可多端接入的通用 Agent 操作层”。

02 它的优点在哪里

1. 同时覆盖 CLI 工作流和消息工作流

很多 agent 项目要么偏“终端内开发助手”，要么偏“聊天平台机器人”。Hermes 想做的是把这两件事合并起来。你可以直接在终端里运行 hermes，也可以启动 gateway 后从 Telegram 或 Discord 上继续同一个助手。

这种设计的好处是，Hermes 不局限于“坐在电脑前时才有用”。如果你把它部署在云端或者 VPS 上，它可以变成一个持续在线的个人 AI 助理。

2. 对“长期使用”考虑得比较完整

Hermes 不只是会聊天和调工具，它还强调长期积累：

有边界的持久记忆，而不是无限堆上下文。
有技能系统，可以把成功流程保存下来复用。
能搜索过去会话，做跨会话召回。
能读取项目里的上下文文件，减少每次重复解释项目背景。

对于经常在固定代码库、固定工作流、固定团队规范里反复工作的用户，这一点很重要。它意味着 agent 不只是“这次帮你做点事”，而是会逐渐更懂你的环境。

3. MCP 支持让扩展性很强

Hermes 官方文档明确支持 MCP，并且说明了 stdio 和 HTTP 两类接入方式。也就是说，只要某个外部系统已经有 MCP server，Hermes 理论上就可以较低成本接进去。

这比每次为单个系统单独写插件更灵活。对于已经在 MCP 生态里积累了一批工具的人，Hermes 的接入成本会低很多。

4. 对 OpenClaw 用户很友好

这一点很有意思。Hermes README 里直接提供了 hermes claw migrate，并写明可以从 OpenClaw 导入配置、记忆、技能、API key、消息平台设置等内容。

这说明它并不是完全无视既有生态重新造轮子，而是明确把一部分 OpenClaw 用户视为潜在迁移对象。

03 怎么快速上手

Hermes Agent 官方推荐的安装方式非常直接：

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

官方说明支持 Linux、macOS、WSL2，以及 Android 的 Termux。需要注意的是，README 里明确写了原生 Windows 暂不支持，Windows 用户建议走 WSL2。

安装完成后，通常先刷新 shell：

`1`	`source ~/.bashrc`

然后就可以直接启动：

hermes

如果你想一步一步完成完整初始化，最省心的命令是：

`1`	`hermes setup`

根据官方文档和 README，首次上手可以按下面这个顺序来：

运行 hermes setup，完成基础配置。
用 hermes model 选择模型提供方和模型。
用 hermes tools 开关需要的工具集。
直接执行 hermes，进入交互式 CLI。
如果你想接 Telegram、Discord 之类的渠道，再继续配置 hermes gateway。

如果你本来就是 OpenClaw 用户，还可以先看一眼迁移命令：

`1`	`hermes claw migrate --dry-run`

它会先预览可迁移的内容，再决定要不要正式导入。

04 和 OpenClaw 怎么看

从官方文档和 README 来看，Hermes Agent 与 OpenClaw 并不是简单的“谁替代谁”，而是定位有明显重叠，但侧重点不同。

Hermes Agent 更像什么

Hermes 更像一个偏 agent 内核和工作流系统的产品。它强调的是：

CLI 体验
记忆与技能沉淀
项目上下文文件
MCP 扩展
子代理并行
在本地、容器、远端、serverless 环境之间切换执行后端

如果你的主要诉求是“让 agent 更懂项目、更能持续复用能力、更方便接 MCP 和开发工作流”，Hermes 的方向会更顺手。

OpenClaw 更像什么

OpenClaw 则更像一个以个人 AI 助手和消息网关为中心的平台。它强调：

非常丰富的消息渠道接入
常驻运行的 Gateway
浏览器里的 Control UI
设备配对、远程访问、状态管理
语音、移动端、Canvas 等更强的助手形态

如果你的核心需求是“把一个个人 AI 助手稳定地挂在各种聊天渠道和设备上”，并且希望用控制面板统一管理，OpenClaw 的产品感会更强。

一个更实用的选择建议

可以把两者简单理解成：

Hermes Agent：更偏“会成长的通用 agent 工作台”
OpenClaw：更偏“多渠道常驻型个人 AI 助手平台”

当然，这个区分不是绝对的，因为两边都在继续扩展能力，而且 Hermes 还提供了从 OpenClaw 迁移的路径。但至少从当前公开资料看，Hermes 在“记忆、技能、上下文、MCP、开发工作流”这条线上更突出；OpenClaw 在“网关、多渠道、控制 UI、设备接入”这条线上更成熟。

05 适合谁尝试

如果你属于下面几类人，Hermes Agent 值得优先试一下：

你已经在终端里大量使用 AI 工具，希望 agent 更懂代码库和项目规则。
你想把 AGENTS.md、技能、记忆、MCP 这些能力组合到一起。
你不想被单一模型厂商锁死，希望可以灵活切换 provider。
你原来就在用 OpenClaw，现在想试试一个更偏 agent 工作流的方向。

如果你更看重的是移动端触达、各种 IM 平台接入、浏览器控制台和“始终在线的个人助理感”，那 OpenClaw 仍然很有吸引力。

参考链接

Hermes Agent GitHub: https://github.com/NousResearch/hermes-agent
Hermes Agent 文档: https://hermes-agent.nousresearch.com/docs/
Hermes Features Overview: https://hermes-agent.nousresearch.com/docs/user-guide/features/overview
Hermes MCP: https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp/
OpenClaw GitHub: https://github.com/openclaw/openclaw
OpenClaw Getting Started: https://docs.openclaw.ai/start/quickstart
OpenClaw Control UI: https://docs.openclaw.ai/web/control-ui

OpenClaw 类脑记忆算法 Dreaming：机器开始做梦，人类却在失眠

Sun, 12 Apr 2026 12:41:34 +0800

大模型的长期记忆一直是个老问题。上下文越积越多，信息越容易混乱。智能体看似什么都记得，实际上却越来越难判断什么重要、什么该忘。

4 月 5 日，OpenClaw 在新版本里上线了一项实验功能：Dreaming。它不是一个花哨名字，而是一套模仿人类睡眠过程的后台记忆整理机制，目标很直接，就是让智能体醒来后记得更准。

01 睡眠算法：把记忆整理拆成三个阶段

Dreaming 并不是简单做索引，而是把记忆整理拆成三个逻辑阶段，对应人类睡眠中的不同功能。

浅睡阶段（Light Sleep）：系统先扫描近期对话和召回记录，做去重和初步筛选，生成候选内容。这个阶段只做暂存，不会直接改动核心记忆文件 MEMORY.md。

深睡阶段（Deep Sleep）：系统开始按规则筛选高价值信息。只有同时达到最低评分、最低召回次数和最低独特查询次数的信息，才会进入下一步。写入前还会重新比对最新日志，剔除过时内容，最后把结果追加到 MEMORY.md，并在 DREAMS.md 中留下深睡摘要。

快速眼动阶段（REM）：在记忆固化之后，系统进一步分析短期行为痕迹，寻找不同信息之间的潜在联系，生成模式总结和反思内容。这部分会写入专门的 REM 区块，帮助智能体在处理复杂任务时更容易抓住全局。

除了给机器自己用的记忆整理机制，Dreaming 还会顺手生成一份更适合人类阅读的“梦境日记”。当素材积累到一定程度，后台子智能体会调用默认模型，在 DREAMS.md 中追加一段简洁说明。

02 评分机制：决定什么该留下，什么该被忘掉

Dreaming 的关键不只是“整理”，更是“筛选”。OpenClaw 没有继续沿用粗放式的全量保存，而是用一套加权评分机制判断哪些信息值得进入长期记忆。

这套机制主要看六个维度：

相关性权重（30%）：衡量信息在被检索时到底有没有用。
频率权重（24%）：统计某条信息被反复提及的次数。
查询多样性（15%）：看它是否在不同问题和场景中都出现过。
时效性权重（15%）：让新近信息拥有更高优先级。
整合度权重（10%）：看信息是否能跨多天稳定出现。
概念丰富度（6%）：判断它背后的关联概念是否足够丰富。

这意味着系统不是把所有内容一股脑塞进长期记忆，而是优先保留那些反复出现、能解决问题、又不过时的信息。

03 它为什么让人联想到 Claude 的“做梦”思路

有开发者认为，OpenClaw 这次 Dreaming 升级的思路，很像 Claude Code 泄露代码中出现过的 KAIROS 自动做梦机制。过去那种反复读写整个 MEMORY.md 的方式，到了后期很容易让记忆系统越来越臃肿；而 Dreaming 把过程拆成浅睡整合、深睡固化、REM 关联，逻辑明显更清晰，也更接近“先整理、再沉淀、再提炼”的思路。

也有人从神经科学角度肯定这套设计。因为 Dreaming、浅睡、深睡和 REM 这些概念并不是随便取的名字，而是明确借用了人类睡眠巩固记忆的模型。

OpenClaw 现有的 IDENTITY.md、USER.md 和 HEARTBEAT.md 已经给了智能体人设、用户上下文和运行连续性，而 DREAMS.md 补上的，正是“哪些记忆该留下”的能力。

04 最讽刺的一幕：机器学会做梦，人却睡不着

Dreaming 的真正价值，不是让 AI 什么都记住，而是让它学会复盘短期记忆、提取底层模式、过滤噪音。一个真正好用的智能体，不应该像移动硬盘一样死记硬背，而应该越来越懂用户的偏好、目标和背景。

从工程角度看，这套机制最值得注意的地方在于它并不神秘。它不是黑盒魔法，而是一套有阶段、有阈值、有反思、也有遗忘规则的后台流程。这种设计让 AI 的记忆机制第一次显得更像“可控的系统”，而不只是“无限堆上下文”。

但也正因为如此，整件事才显得有点讽刺：我们正在投入大量资源，教机器如何像人一样做梦；与此同时，许多人却因为担心被这些越来越聪明的系统取代而失眠。

抛弃 MCP？为什么 CLI 正在成为 Agent 的默认工具层

Fri, 10 Apr 2026 21:55:12 +0800

过去一年，关于 Agent 工具链的争论越来越集中在一个问题上：

MCP（Model Context Protocol）是让工具调用更简单了，还是把原本简单的事情复杂化了？

在大多数日常开发任务里，CLI 正在成为更实用的默认方案。

成本差异不是“体验问题”，是数量级问题

MCP 最大的现实压力是 token 开销。

常见场景里，MCP 在真正执行任务前，需要先加载大量工具 schema。以 GitHub MCP Server 为例，初始化就可能消耗数万 tokens。对于长任务来说，这会直接挤占上下文预算。

社区基准测试也反复指向同一个结论：

MCP 单次调用成本常见是 CLI 的数倍到数十倍
失败重试成本也更高（要重建连接、重新加载上下文）

这不是“慢一点”的差距，而是会放大成 API 费用、时延和稳定性问题。

为什么模型天然更“会用 CLI”

一个常被忽略的事实是训练分布。

LLM 在训练中看过海量终端文本：命令、输出、报错、脚本、man page。也就是说，CLI 交互模式本来就接近模型的“母语输入”。

相反，MCP 的 JSON-RPC 与 tool schema 是近两年才大规模出现的新范式。模型当然能学会，但熟悉度和压缩效率通常不如 CLI 这类历史语料。

这也解释了为什么很多时候：

同样目标，CLI 指令更短
输出更适合直接继续推理
错误恢复路径更稳定

安全与隔离：MCP 还有补课空间

MCP 不是不能做安全，而是生态还在早期。

当前常见担忧包括：

工具描述投毒（Tool Poisoning）
服务行为漂移（Rug Pull）
同名工具覆盖（Shadowing）

CLI 当然也有安全问题（注入、越权、路径风险），但其进程模型、权限边界、审计链路已经经过几十年工程实践验证。对生产环境而言，这种“可预期性”很重要。

这不等于 MCP 没价值

我不认为 MCP 应该被抛弃。

更合理的定位是：

CLI 负责执行层（本地、低延迟、高频调用）
MCP 负责连接层（远程服务发现、统一认证、审计与多租户）

也就是常说的混合架构：CLI + MCP Gateway。

在需要对接大量远程系统、做统一权限治理和合规审计时，MCP 仍然有明显价值；但在“让 Agent 快速完成开发任务”这件事上，CLI-first 往往更符合当前模型能力边界。

在今天的工程现实里，CLI 更像 Agent 的工作母语；MCP 更适合作为连接协议，而不是唯一执行协议。

OpenClaw 与 Agent Harness：为什么它看起来像 AGI

Fri, 10 Apr 2026 09:16:17 +0800

很多人第一次接触 OpenClaw，会觉得它“比聊天机器人更像一个会做事的同事”。

这种感觉并不神秘。关键在于：OpenClaw 不是单一模型能力的跃迁，而是一个完整的 Agent Harness。

先给结论

OpenClaw 的本质可以概括为：

模型负责理解与决策
Harness 负责记忆、工具、触发、执行与输出
两者通过循环协作，形成“持续行动”的体验

所以它“像 AGI”的核心原因，不是模型突然变成全能，而是系统工程把模型的可执行性放大了。

什么是 Harness

可以把 Harness 理解为“给模型穿上的外骨骼”。

单独的 LLM 通常只能在一次请求里给出回答，而 Harness 会补齐这些能力：

会话与状态管理：把多轮任务串起来
记忆机制：保存并按需召回上下文
工具系统：调用浏览器、终端、文件与外部 API
触发机制：由定时器或事件唤醒，不必每次都等人提问
输出通道：把结果写回系统，而不只是回一段文字

当这些能力被接入同一个循环时，模型就从“回答器”变成“执行器”。

OpenClaw 为什么显得不一样

传统聊天机器人是“问一次，答一次”。

OpenClaw 更像“观察 -> 调工具 -> 看结果 -> 再决策”的闭环。闭环一旦成立，就会表现出持续推进任务的能力。

这也是 OpenClaw 最值得学习的地方：

它证明了 Agent 体验主要来自架构设计
它把“自治”拆成了可工程化的模块

价值与边界

OpenClaw 的优势是通用、灵活，但代价也明显：

上下文与工具定义越多，成本越高
系统越通用，调试和治理越复杂

在生产场景里，很多团队会选择更小、更专的 Agent，而不是一个“全能智能体”。

Anthropic 封杀 OpenClaw 的完整时间线

Wed, 08 Apr 2026 19:48:42 +0800

事件背景

2026 年 4 月 4 日，Anthropic 宣布切断 Claude 订阅对 OpenClaw 等第三方工具的覆盖。

对用户层面的直接影响是：原先依赖订阅路径接入 Claude 的第三方流程，需要改为其他接入方式或切换到其他模型。

时间线（2026 年 1 月至 4 月）

2026 年 1 月

据公开报道，Anthropic 要求当时名为 Clawdbot 的项目调整名称，理由是发音与 Claude 接近。

同一阶段，社区开始出现关于第三方通过订阅凭证调用能力受限的反馈。

2026 年 2 月

相关限制被写入服务条款，订阅与第三方自动化调用之间的边界进一步明确。

同月，OpenClaw 发布 v4.0，底层架构改为可插拔模型后端。也就是说，模型不再是单一固定入口，而是可以在多个模型提供方之间切换。

2026 年 3 月

Anthropic 发布 Claude Dispatch 与 Computer Use，覆盖远程任务执行与桌面操作等能力。

OpenClaw 在后续更新中继续推进兼容层，统一不同模型在认证方式、工具调用格式和返回结构上的差异，降低切换模型时的迁移成本。

公开报道还提到，OpenClaw 团队与 Anthropic 在 3 月下旬有过沟通，但最终策略方向未发生改变。

2026 年 4 月 4 日

Anthropic 正式执行对第三方工具的订阅覆盖切断。

这标志着此前数月的策略调整进入执行阶段。

2026 年 4 月 5 日

OpenClaw 发布 v4.5，主要动作包括：

在引导流程中调整模型入口优先级
接入 GPT-5.4 等替代模型路径
继续针对任务流程与交互体验做适配

从发布时间看，OpenClaw 的切换能力并非完全临时构建，而是建立在 2 月以来的多模型架构改造基础上。

过程中的两个并行方向

按时间线看，双方在同一时期分别推进了不同方向：

Anthropic：收紧订阅边界，推动官方产品能力整合
OpenClaw：强化模型可替换性，提升跨模型兼容能力

这两条路线并不矛盾，但会在“入口归属”和“用户工作流沉淀位置”上产生竞争关系。

当前状态（截至 2026 年 4 月）

基于已公开的信息，可以确认以下事实：

订阅覆盖切断已执行
OpenClaw 已完成主要模型路径切换并保持版本迭代
用户是否感知明显变化，取决于其原有工作流对单一模型能力的依赖程度

后续观察点

接下来更值得关注的，不是单次事件本身，而是三件事：

订阅方案与 API 调用边界是否继续细化
多模型 Agent 在稳定性、成本和体验上的长期表现
用户工作流最终沉淀在模型层、工具层，还是两者之间的混合层

模型	适合场景
`deepseek-v4-flash`	日常代码阅读、批量改小问题、生成脚本、整理上下文、低风险前端修改
`deepseek-v4-pro`	架构规划、复杂 bug、跨文件重构、事实核查、多工具调用、高风险改动