MCP on KnightLi的博客

Claude Code 也有插件市场了：能装什么、怎么装、要注意什么

Sat, 23 May 2026 19:03:30 +0800

anthropics/claude-plugins-official 是 Anthropic 管理的 Claude Code 官方插件目录。它不是一个普通代码库，而是一个可被 Claude Code 插件系统直接使用的 marketplace，集中放置经过 Anthropic 维护或筛选的 Claude Code 插件。

这个仓库值得关注，是因为 Claude Code 正在从“一个 AI 编程命令行工具”变成“可扩展的开发环境”。插件可以把 Skills、Agents、Hooks、MCP servers、LSP servers、后台监控和默认设置打包起来，让团队或社区用统一方式分发。

这个仓库是什么

仓库 README 对它的定位很直接：这是一个高质量 Claude Code 插件的 curated directory。

目录主要分成两块：

/plugins：Anthropic 内部开发和维护的插件。
/external_plugins：来自合作伙伴和社区的第三方插件。

也就是说，它既包含官方能力，也包含经过收录的外部生态入口。对普通用户来说，最直接的意义是可以通过 Claude Code 的 /plugin 系统发现和安装插件；对开发者来说，它提供了观察 Claude Code 插件格式和生态方向的窗口。

如何安装插件

README 给出的安装方式很简单。可以直接通过 Claude Code 的插件系统安装：

`1`	`/plugin install {plugin-name}@claude-plugins-official`

也可以在 Claude Code 里打开插件发现入口：

`1`	`/plugin > Discover`

这里的关键点是 @claude-plugins-official。它代表官方插件目录这个 marketplace。根据 Claude Code 文档，claude-plugins-official 是 Anthropic 维护的官方 marketplace，并且会在 Claude Code 安装中默认可用。

插件长什么样

仓库 README 给出了标准插件结构：

plugin-name/
├── .claude-plugin/
│   └── plugin.json
├── .mcp.json
├── commands/
├── agents/
├── skills/
└── README.md

其中 .claude-plugin/plugin.json 是插件元数据文件，通常用来声明插件名、描述、版本、作者等信息。其他目录则按需存在：

skills/：放 Claude 可自动调用的技能说明。
commands/：放 slash commands。
agents/：放自定义 agent 定义。
hooks/：放事件触发逻辑。
.mcp.json：配置 MCP server。
.lsp.json：配置语言服务器。
monitors/：配置后台监控。
settings.json：给插件附带默认设置。

这说明 Claude Code 插件不是单一类型扩展，而是一种打包格式。它可以只是一个小命令，也可以是一整套面向某个技术栈的工作流。

官方目录里已经有哪些方向

从 /plugins 目录看，官方维护插件覆盖了不少开发场景，包括：

LSP 类插件：typescript-lsp、pyright-lsp、rust-analyzer-lsp、gopls-lsp、clangd-lsp、csharp-lsp、jdtls-lsp、kotlin-lsp、lua-lsp、php-lsp、ruby-lsp、swift-lsp。
编程工作流：code-review、feature-dev、code-modernization、code-simplifier、commit-commands、pr-review-toolkit。
Claude Code 配置和插件开发：claude-code-setup、claude-md-management、plugin-dev、skill-creator、mcp-server-dev。
输出风格和专项能力：explanatory-output-style、learning-output-style、security-guidance、session-report、math-olympiad。

/external_plugins 里则能看到更多第三方工具和服务方向，例如 github、gitlab、linear、asana、firebase、playwright、terraform、context7、serena、telegram、discord 等。

这组插件透露出一个趋势：Claude Code 不只是想帮你改文件，还想接入代码智能、项目管理、云服务、测试、基础设施和团队协作工具。

为什么插件系统重要

过去很多 Claude Code 自定义能力都可能散落在项目里的 .claude/ 目录中，比如 commands、agents、skills 或 hooks。这种方式适合个人或单个项目，但不方便跨项目复用，也不方便团队统一分发和更新。

插件解决的是可复用和可分发问题：

同一套配置可以跨多个项目安装。
命令和技能有命名空间，减少冲突。
插件可以通过 marketplace 发布和更新。
团队可以把内部最佳实践打包成标准插件。
社区可以围绕某个框架、语言或服务维护专门扩展。

这和 VS Code 插件、JetBrains 插件、浏览器扩展的思路类似：当一个工具开始有稳定插件生态，它就不再只是单一产品，而是在形成平台。

对开发者有什么用

如果你只是 Claude Code 用户，这个仓库最实用的地方是找插件。比如需要 TypeScript、Python、Rust 或 Go 的 LSP 能力，可以先看官方目录里是否已有对应插件；需要 PR review、commit、代码现代化等工作流，也可以从官方插件开始试。

如果你是插件开发者，这个仓库更像样板库。你可以参考它的目录组织、plugin.json 写法、README 说明方式，以及 Anthropic 如何把 skills、agents、MCP、LSP 和 hooks 组合起来。

Claude Code 文档也明确建议：如果只是单项目自定义，可以先用 .claude/；如果需要分享给团队、跨项目复用、版本化发布，或者进入 marketplace，就应该做成插件。

安全边界不能忽略

仓库 README 在开头就提醒：安装、更新或使用插件前必须信任该插件。原因很简单，插件可能包含 MCP server、文件、脚本或其他软件。Anthropic 维护目录，不等于能保证每个插件在你的本地环境中都按你预期运行。

实际使用时建议至少做几件事：

安装前看插件主页和 README。
检查是否包含 .mcp.json、hooks、可执行脚本或后台监控。
对需要访问账号、代码仓库、聊天工具、云服务的插件格外谨慎。
在重要项目中启用插件前，先在测试仓库验证。
团队环境最好统一审核插件来源和版本。

AI 编程插件的权限往往比普通编辑器主题高得多。它可能能读项目文件、调用外部服务、启动本地命令，甚至影响提交和部署流程，所以信任边界要比“装一个小工具”更严格。

和社区 marketplace 的关系

Claude Code 文档提到，Anthropic 维护两个公开插件 marketplace：

claude-plugins-official：Anthropic 维护的 curated 插件集合。
claude-community：第三方提交后进入审查流程的社区插件目录。

这两者的定位不同。社区插件可以通过提交表单进入 review；官方目录则由 Anthropic 自行决定是否收录，没有普通申请流程。换句话说，claude-plugins-official 更像官方精选目录，claude-community 更像开放社区目录。

小结

anthropics/claude-plugins-official 的意义不只是“多了一个 GitHub 仓库”。它说明 Claude Code 的扩展机制正在平台化：Skills、Agents、Hooks、MCP、LSP、后台监控和默认设置都可以被打包、安装、更新和分发。

对个人开发者来说，官方插件目录能降低配置 Claude Code 的门槛。对团队来说，它提供了把内部流程标准化的路径。对插件开发者来说，它给出了 Anthropic 认可的插件结构和生态方向。

接下来值得关注的不是某一个插件本身，而是 Claude Code 插件生态会不会形成稳定分层：官方精选、社区插件、团队私有 marketplace，以及围绕主流语言、框架和 SaaS 服务的专门扩展。如果这条路线走通，Claude Code 会越来越像一个可编排的 AI 开发平台，而不只是一个命令行助手。

参考资料：

GitHub 项目：https://github.com/anthropics/claude-plugins-official
Claude Code 插件文档：https://code.claude.com/docs/en/plugins

Graphify 解决 Claude Code 最大局限：把代码库变成 AI 可查询知识图谱

Thu, 21 May 2026 08:02:32 +0800

safishamsi/graphify 是一个面向 AI 编程助手的知识图谱工具。它的目标很直接：把一个项目目录里的代码、文档、SQL schema、脚本、论文、图片、视频和音频，整理成可查询的知识图谱，让 AI 助手不再只靠 grep、全文阅读或临时搜索来理解项目。

项目地址：safishamsi/graphify

截至本文整理时，GitHub 页面显示项目约有 50.2k stars、5.4k forks，许可证为 MIT。README 对它的描述是：在 AI 编程助手里输入 /graphify，它就会把整个项目映射成一个可以查询的知识图谱。

它解决的核心问题

AI 编程助手越来越强，但在真实代码库里仍然经常遇到几个问题：

不知道关键模块之间怎么连接。
读了很多文件，但没形成整体架构地图。
搜索命中了文本，却不知道上下游依赖。
代码、数据库 schema、文档和基础设施配置分散在不同地方。
多人协作时，每个人对项目结构的理解不一致。

Graphify 想做的是给项目生成一层“记忆层”。它把代码实体、文档概念、数据库表、配置、设计说明和跨文件关系连接起来，让 AI 助手可以按图谱查询，而不是每次从零开始扫文件。

最小使用方式

Graphify 的最小用法非常简单。安装后，在 AI 编程助手里输入：

`1`	`/graphify .`

在 PowerShell 里要注意，前导 / 会被当成路径分隔符，所以 Windows PowerShell 下应使用：

`1`	`graphify .`

运行后会生成 graphify-out/ 目录，核心文件包括：

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

这三个文件分工不同：

graph.html：浏览器里打开的交互式图谱，可以点击节点、过滤和搜索。
GRAPH_REPORT.md：项目亮点、关键概念、意外连接和推荐问题。
graph.json：完整图谱，后续可以直接查询，不必重新读所有文件。

如果想生成更可读的架构页面和 Mermaid 调用流图，可以运行：

`1`	`graphify export callflow-html`

安装和平台支持

Graphify 的 PyPI 包名是 graphifyy，注意是双 y。README 特别提醒，PyPI 上其他 graphify* 包并不属于该项目，但 CLI 命令仍然叫 graphify。

推荐安装方式是：

`1`	`uv tool install graphifyy`

也可以使用：

1
2

pipx install graphifyy
pip install graphifyy

安装后注册到 AI 助手：

`1`	`graphify install`

项目支持的平台很多，包括 Claude Code、Codex、OpenCode、GitHub Copilot CLI、VS Code Copilot Chat、Aider、Cursor、Gemini CLI、Kimi Code、Kiro、Google Antigravity 等。不同平台可以用不同安装命令，例如：

graphify install --platform codex
graphify install --platform gemini
graphify cursor install
graphify antigravity install

Codex 用户还需要在 ~/.codex/config.toml 的 [features] 下加入：

`1`	`multi_agent = true`

README 也说明，Codex 使用 $graphify，不是 /graphify。

它能处理哪些文件

Graphify 覆盖的输入类型很广。

代码方面，它支持 31 种语言，包括 Python、TypeScript、JavaScript、Go、Rust、Java、C/C++、Ruby、C#、Kotlin、Scala、PHP、Swift、Lua、Zig、PowerShell、SQL、Shell、JSON 等。

文档方面，它支持：

.md
.mdx
.qmd
.html
.txt
.rst
.yaml
.yml

还可以通过可选依赖扩展更多类型：

pip install "graphifyy[pdf]"
pip install "graphifyy[office]"
pip install "graphifyy[video]"
pip install "graphifyy[mcp]"
pip install "graphifyy[neo4j]"
pip install "graphifyy[sql]"
pip install "graphifyy[all]"

其中，pdf 用于 PDF 提取，office 用于 .docx 和 .xlsx，video 用于视频和音频转写，mcp 用于 MCP stdio server，neo4j 用于推送到 Neo4j，sql 用于 SQL schema 提取。

生成的报告有什么价值

GRAPH_REPORT.md 不是普通摘要，它会把项目里更值得 AI 助手关注的关系挑出来。

README 里提到的报告内容包括：

God nodes：项目里连接最多的核心概念。
Surprising connections：跨文件、跨模块的意外连接。
The why：从注释、docstring、设计文档里提取出的设计理由。
Suggested questions：图谱特别适合回答的问题。
Confidence tags：关系会标记为 EXTRACTED、INFERRED 或 AMBIGUOUS。

这点很关键。普通搜索只能告诉你“哪里出现了这个词”，而图谱可以回答“这个概念和哪些模块、配置、表、文档有关”。对大型代码库来说，这比单纯全文检索更接近架构理解。

常用命令

Graphify 的常见命令包括：

/graphify .
/graphify ./docs --update
/graphify . --cluster-only
/graphify . --no-viz
/graphify . --wiki
graphify export callflow-html
/graphify query "what connects auth to the database?"
/graphify path "UserService" "DatabasePool"
/graphify explain "RateLimiter"

也可以把论文或视频加入图谱：

1
2

/graphify add https://arxiv.org/abs/1706.03762
/graphify add <youtube-url>

如果要做 PR 辅助分析，还可以使用：

graphify prs
graphify prs 42
graphify prs --triage
graphify prs --conflicts

这类命令适合代码评审场景：看 PR 影响了哪些图谱社区、是否和其他 PR 有冲突风险、哪些 review queue 更值得优先处理。

和 MCP、Neo4j、CI 的关系

Graphify 不只是生成 HTML 图。它也可以把图谱暴露给 AI 助手反复调用。

例如可以启动 MCP server：

`1`	`python -m graphify.serve graphify-out/graph.json`

MCP server 提供的能力包括 query_graph、get_node、get_neighbors、shortest_path、list_prs、get_pr_impact、triage_prs 等。

它也支持 Neo4j 导出或推送：

1
2

/graphify ./raw --neo4j
/graphify ./raw --neo4j-push bolt://localhost:7687

团队协作上，README 建议可以提交 graphify-out/，让团队每个人拉取后都能共享同一份项目地图。还可以运行：

`1`	`graphify hook install`

这样每次 git commit 后自动重建图谱，并设置 merge driver，避免 graph.json 在多人并行提交时留下冲突标记。

隐私和成本要怎么看

Graphify 的 README 对隐私边界写得比较清楚。

代码文件会通过 tree-sitter 在本地解析，不会发出 API 调用。视频和音频可以通过 faster-whisper 本地转写。文档、PDF、图片这类语义提取内容，则会通过你的 AI 助手模型 API 处理。

如果用 headless graphify extract，可能需要设置这些环境变量：

ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
OPENAI_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY
OLLAMA_BASE_URL

本地 Ollama、AWS Bedrock、Claude Code CLI 等也可以作为 backend。README 还写明项目没有 telemetry、usage tracking 和 analytics。

实际使用时要注意：代码本地解析不等于所有内容都不出网。涉及文档、PDF、图片或云端模型时，仍然要看 backend、API key、企业合规和数据边界。

适合哪些场景

Graphify 适合几类用户：

想让 Claude Code、Codex、Cursor、Gemini CLI 更懂项目结构的开发者。
需要快速理解大型陌生代码库的人。
需要把代码、SQL schema、文档、配置放在一起分析的团队。
做架构审查、PR review、重构影响分析的人。
希望把项目知识暴露成 MCP 工具给 Agent 使用的人。
想为团队保留“项目地图”的技术负责人。

它不一定适合所有项目。小型脚本、一次性 demo、结构非常简单的仓库，用普通搜索和 README 可能已经够用。Graphify 的价值更容易出现在模块多、文档多、团队协作多、AI 助手频繁参与开发的大项目里。

小结

Graphify 的意义在于，它把 AI 编程助手的上下文从“临时读取文件”推进到“长期可查询的项目知识图谱”。

对开发者来说，它不是替代 IDE、搜索或 LSP，而是给 AI 助手补一层结构化记忆：哪些模块重要、哪些概念连接紧密、哪些文档解释了设计理由、某个 PR 会影响哪些社区。随着 Codex、Claude Code、Gemini CLI、Antigravity 这类 Agent 工具继续普及，这类“项目图谱层”会越来越有用。

参考来源：

GitHub：safishamsi/graphify

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

内容发太多平台太累？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

Claude Code 省 Token 指南：模型、MCP、CLAUDE.md 和 Skills 怎么影响缓存

Mon, 18 May 2026 18:30:24 +0800

Claude Code 长任务里，Prompt Cache 命中率会直接影响成本和速度。很多人只知道“缓存能省 Token”，但不清楚哪些操作会让缓存突然失效。

理解它并不难：每次请求都可以看成一条从左到右的上下文链条：

`1`	`tools -> system -> CLAUDE.md / skills -> messages`

越靠左的内容越稳定，缓存收益越大；越靠左的内容一变，后面的缓存也更容易跟着失效。反过来，越靠右的内容变化，影响范围越小。

所以优化 Claude Code 的 Prompt Cache，不是靠玄学，而是靠一个原则：任务开始前把模型、MCP、Skills、CLAUDE.md 等基础上下文准备好，任务中途尽量不要改。

Prompt Cache 缓存的不是文字本身

Prompt Cache 不是简单地把提示词字符串存起来。对 Transformer 模型来说，更关键的是前缀上下文经过注意力层计算后的 Key/Value 状态，也就是常说的 KV cache。

这意味着两个事实：

同一段上下文，只要前缀保持稳定，就可以在后续请求中复用一部分计算结果。
如果模型、工具定义、系统提示词或前缀消息发生变化，之前的缓存就可能无法复用。

Anthropic 官方文档也把失效层级概括为 tools -> system -> messages。工具定义变化会影响整段缓存，系统层变化会影响 system 和 messages，messages 层变化则主要影响消息缓存。

Claude Code 里还会额外涉及 CLAUDE.md、Skills、MCP、插件和子代理等上下文，所以实际使用时更容易踩到缓存失效点。

缓存杀手一：中途切换模型

切模型是影响最大的操作。

Prompt Cache 是按模型隔离的。Opus、Sonnet、Haiku 这类模型的结构和权重不同，同一段文本算出来的 KV cache 也不同。你在 Opus 里跑了很长上下文，再切到 Sonnet，并不能让 Sonnet 复用 Opus 的缓存。

这会带来一个反直觉结果：中途为了省钱切模型，可能反而让前面已经积累的缓存全部失效。原本可以按 cache read 价格读取的上下文，需要重新写入和计算。

更稳妥的做法是：

主对话尽量固定一个模型。
需要便宜模型处理支线任务时，用 subagent 隔离出去。
让支线代理完成搜索、探索、整理，再把结果摘要交回主对话。

这样主对话的长上下文尽量不动，缓存命中率更稳定。

缓存杀手二：中途新增 MCP 或重载插件

MCP 会向 Claude Code 提供工具。新增 MCP 服务器后，工具列表会变化，而工具定义处在上下文链条最左侧。

从 Prompt Cache 的角度看，工具列表一变，后面的 system 和 messages 都可能需要重新计算。尤其是 MCP 很多时，工具定义本身就可能占用大量 Token，缓存失效的代价会很明显。

不过有一个细节：Claude Code 通常在会话启动时读取 MCP 配置。你中途改了配置，当前 session 不一定立刻受影响。真正需要小心的是触发重新加载的动作，例如重启、恢复会话、重新加载插件或让工具列表重新组装。

建议是：

开始长任务前，一次性装好需要的 MCP。
不要做一半才发现缺工具，再安装并重载。
对大型 MCP 工具集，优先考虑按需加载或减少默认启用数量。
不常用的 MCP 不要长期挂在默认配置里。

如果工具定义稳定，Prompt Cache 才有长期命中的基础。

缓存杀手三：中途修改 CLAUDE.md

CLAUDE.md 是 Claude Code 的项目记忆文件，适合放构建命令、测试命令、架构约定、代码风格和项目注意事项。

它对 Claude Code 很有用，但也会进入上下文。官方帮助文档说明，CLAUDE.md 会在 session 开始时读取，并作为用户消息提供给 Claude；它也会使用 Anthropic 的 Prompt Cache。首次请求会按完整输入计费，后续请求如果在缓存有效期内命中，就按更低的 cache read 成本处理。

问题在于：CLAUDE.md 是内容寻址的。你一改文件内容，旧缓存就对不上了。

所以不要在长任务中途频繁改 CLAUDE.md。更好的方式是：

任务开始前先检查 CLAUDE.md 是否够用。
把稳定规则写进去，把临时指令放在当前对话里。
如果只是一次性任务，不要为了临时需求修改长期记忆文件。
如果必须改，最好在一个阶段结束后再开始新 session。

CLAUDE.md 应该是稳定的项目说明，而不是每轮任务都改的便签。

缓存杀手四：中途安装或更新 Skills

Skills 也是上下文的一部分。安装新 Skill、更新 Skill，或者让 Skill 列表发生变化，都会让注入到会话里的上下文不同。

这类变化通常不会在当前 session 里立刻完整生效，而是在重新加载、恢复会话或新开会话时体现出来。问题是，一旦重新组装 messages，旧缓存就可能命中不了。

建议和 MCP 类似：

开始任务前先确认需要哪些 Skills。
同一类任务尽量固定 Skill 集合。
不要在一个长任务中途边做边装 Skill。
如果安装了新 Skill，最好把它当成新阶段的开始。

对经常做内容生产、代码审查、部署、翻译的工作流，可以把常用 Skills 固定下来，让上下文结构尽量稳定。

缓存杀手五：空闲时间超过 TTL

Prompt Cache 不是永久保存。常见默认有效期是几分钟级别，Anthropic 文档和 Claude Code 相关说明里都提到过 5 分钟左右的缓存窗口。超过 TTL 后，即使你发送完全一样的请求，服务端也可能已经清掉缓存。

这也是很多长任务用户的体感来源：刚才还很省，去喝杯咖啡回来，再发下一步，Token 又突然涨上去了。

长任务尤其容易遇到这个问题。你可能要看 Claude Code 的输出、检查文件、跑测试、思考下一步，这些操作一不小心就超过 5 分钟。

如果你的使用环境支持，可以在长任务前启用 1 小时 Prompt Cache TTL：

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

在 Windows PowerShell 里可以写成：

`1`	`$env:ENABLE_PROMPT_CACHING_1H="1"`

需要注意的是，1 小时缓存写入成本通常会高于 5 分钟缓存写入成本。它不适合所有短任务，但对大型代码库、长对话、复杂多步骤开发任务，往往比频繁缓存过期更划算。

怎么安排一次更省 Token 的 Claude Code 长任务

比较稳的流程可以这样做：

任务开始前选定模型，不要中途频繁切换。
提前启用需要的 MCP，不用的 MCP 先关掉。
检查 CLAUDE.md，只保留稳定、关键、长期有效的规则。
提前准备好本次任务需要的 Skills。
如果是复杂任务，考虑启用 1 小时 TTL。
把大任务拆成几个阶段，但每个阶段内部尽量保持上下文结构稳定。
需要探索支线问题时，用 subagent 或单独 session，不要污染主对话。

这套做法的目标不是绝对不让缓存失效，而是避免那些代价最高、最容易被忽略的失效。

一个简单判断标准

你可以用一句话判断某个操作是否危险：

这个操作会不会改变模型、工具定义、系统上下文或会话开头的固定消息？

如果答案是会，那它大概率会影响 Prompt Cache。越靠近上下文链条左侧，影响越大。

常见操作可以这样理解：

切模型：高风险，模型缓存隔离。
新增 MCP 或重载插件：高风险，工具列表变化。
修改 CLAUDE.md：中高风险，项目记忆变化。
安装 Skills：中高风险，注入上下文变化。
普通对话继续追问：低风险，主要追加 messages。
空闲超过 TTL：高风险，服务端缓存过期。

小结

Claude Code 的 Prompt Cache 优化，关键不是背参数，而是让会话前缀稳定。

模型不要随便切，MCP 和 Skills 不要边做边装，CLAUDE.md 不要当临时草稿频繁改，复杂任务尽量延长 TTL。只要这些基础动作稳定下来，Claude Code 在长任务里的 Token 成本和响应速度都会更可控。

最实用的一句话是：开始前配好，开始后少动。

参考资料

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 真正难的地方。

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 产品是否有长期价值，可以问一个问题：当这个能力被下一代模型或平台内置后，它还剩下什么？

答案如果是领域流程、真实数据、可验证结果和用户信任，那才可能是长期价值。

Claude 连接 Fusion 360：用 AI 修改 STEP 模型的一个实例

Thu, 14 May 2026 20:58:04 +0800

Claude 连接 Fusion 360 之后，可以不只是“讲思路”，而是直接参与 CAD 模型修改。一个典型场景是：打开已有的 STEP 文件，让 Claude 读取当前模型、分析结构冲突、规划尺寸，再通过 Fusion 插件执行建模修改。

下面用一个行星齿轮分度器的修改过程，整理 Claude + Fusion 360 的基本使用方法。

先启用 Fusion 360 的 API/MCP 服务

在 Fusion 360 里先做一次基础设置：

打开右上角的 Preferences。
进入 General 或“通用”设置。
找到 API 选项。
打开 MCP server。
记下端口号，默认示例是 27182。

然后回到 Claude，进入 Connectors，找到 Fusion 连接器，填入 Fusion 360 的地址和端口。端口一般使用默认的 27182 即可。

连接成功后，Claude 就可以通过 Fusion 插件和当前打开的模型交互。

打开 STEP 文件并明确修改目标

这次要修改的是行星齿轮分度器里的一个齿轮。原始设计里，这个齿轮通过一颗螺丝作为中心轴固定在支架上。

目标是把它改成轴承结构：

中心孔需要适配轴承；
周围螺丝孔不能和扩大的中心孔干涉；
支架上的自攻螺丝孔位也要调整为适合轴承旋转的轴心结构；
最终模型要能导入切片软件并用于 3D 打印。

这里的关键是，不要只告诉 Claude“帮我改一下”。要把用途、装配方式、材料和制造工艺说清楚。

Claude 可以通过截图理解当前模型

之前有人会担心 Fusion 插件只能执行命令，不能让 Claude 看到模型。实际测试里，Claude 可以通过截图方式识别当前模型状态。

在这个案例里，Claude 能看到齿轮结构，并完成几件事：

识别齿轮和中心孔；
测量或估算相关尺寸；
推荐轴承尺寸；
判断哪些结构会影响轴承安装；
发现中心孔扩大后，周围螺丝孔可能发生几何干涉。

这一步很重要。它说明 Claude 不只是按文字指令盲改，而是可以结合当前模型视图做结构判断。

材料和加工方式必须提前说明

如果模型最终用于 3D 打印，必须明确告诉 Claude 材料和工艺。

例如使用 PLA 打印时，轴承孔不能完全按 CNC 金属加工的公差来设计。直径为 6mm 的轴承，如果需要压入配合，可以考虑把孔径设为约 6.1mm。这个尺寸是否合适，还要结合打印机精度、材料收缩、切片参数和实际测试调整。

如果不说明材料，Claude 可能默认按 CNC 加工思路给尺寸。这样得到的孔径对 3D 打印来说可能偏小，后续装配会很难。

建议在提示里写清楚：

1
2
3

这个模型用于 FDM 3D 打印，材料是 PLA。
目标是安装直径 6mm 的轴承，需要考虑打印公差和压入配合。
请不要按 CNC 金属加工公差处理。

让 Claude 修改齿轮结构

明确目标后，可以让 Claude 执行具体修改：

扩大中心孔；
调整周围干涉的螺丝孔；
增加轴承安装座；
对边缘加倒角；
保持齿轮主体和关键啮合结构不变。

在这个案例里，Claude 会先给出规划，再调用 Fusion 360 完成建模操作。比如它发现原有螺丝孔和中心孔冲突后，会把孔位向外移动一点，避免轴承安装空间被破坏。

修改完成后，可以检查模型：

中心轴承座是否成型；
周围孔位是否还保留功能；
齿轮结构是否被误伤；
倒角是否影响装配；
是否存在悬空、薄壁或切片风险。

支架也要一起修改

只改齿轮还不够。原支架上原本是自攻螺丝安装孔，如果齿轮中心改为轴承，支架也要配合改成轴承轴心结构。

可以让 Claude 对支架执行类似修改：

保留整体安装位置；
把原来的自攻螺丝孔改为柱状轴心；
控制轴心直径和高度；
给轴承旋转预留空间；
避免和支架其他结构干涉。

这样打印出来后，齿轮可以顺利压入轴承，支架也能提供新的旋转中心。最终效果是原本靠螺丝固定的结构，变成更顺滑的轴承旋转结构。

导出、切片和打印验证

CAD 修改完成后，还需要进入实际制造流程：

从 Fusion 360 导出修改后的模型。
导入切片软件。
检查孔洞、薄壁、悬垂和支撑。
打印齿轮和支架。
实际压入轴承。
检查旋转是否顺滑。

AI 修改 CAD 的结果不能只看屏幕上的模型是否漂亮，必须打印验证。尤其是轴承、孔位、卡扣、齿轮这类机械结构，0.1mm 级别的误差就可能决定能不能装上、转得顺不顺。

使用建议

Claude + Fusion 360 适合做这类任务：

在已有 STEP 模型上做局部改造；
调整孔位、倒角、支架、安装座；
把螺丝固定改成轴承、卡扣或插销结构；
给 3D 打印模型做公差修正；
快速生成多个改版方案。

但它不适合完全不检查地直接出最终件。更稳妥的流程是：

人先定义装配目标和材料工艺。
Claude 负责分析结构并提出修改方案。
Claude 调用 Fusion 执行建模。
人检查关键尺寸和干涉。
打印小样验证。
根据实物结果再迭代。

小结

Claude 连接 Fusion 360 的价值，不在于替代 CAD 基础知识，而在于把“已有模型的局部修改”变得更快。

只要把目标、材料、尺寸、公差和装配方式说清楚，它可以帮你读模型、找干涉、改结构、加倒角，再把模型推进到可打印状态。对于 3D 打印、开源机械件改造和个人工作室的小批量迭代来说，这类 AI CAD 工作流已经很实用。

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、扩展和执行行为都符合预期，再逐步扩大使用范围。

参考资料

CC Switch：一个桌面工具统一管理 Claude Code、Codex、Gemini CLI 和 OpenClaw

Wed, 06 May 2026 09:03:08 +0800

CC Switch 是一个面向 AI 编程重度用户的桌面管理工具。它要解决的问题很直接：现在很多人同时使用 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw，但每个工具都有自己的配置格式、Provider 写法、MCP 配置和 Skills 管理方式。

当你只用一个工具时，手动改配置还能忍；一旦多个工具混用，再加上官方账号、第三方 API、中转服务、本地模型和团队共享配置，手动编辑 JSON、TOML、.env 很快就会变成一件很烦的事。

CC Switch 的定位，就是把这些分散配置收进一个跨平台桌面应用里。

它解决什么问题

现代 AI 编程工具越来越像“命令行里的开发同事”，但每个工具的生态还没有完全统一。

常见痛点包括：

Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 配置格式不同。
切换 API Provider 时，要反复改配置文件。
MCP server 在不同工具之间重复配置。
CLAUDE.md、AGENTS.md、GEMINI.md 这类提示文件难以统一维护。
Skills 安装、同步、备份和卸载缺少一个集中入口。
多个账号、多个 relay、多个模型服务切换很容易搞混。
配置文件手工修改出错后，排查成本很高。

CC Switch 的思路是：不要让用户记住每个工具的配置细节，而是用一个统一界面管理 Provider、MCP、Prompts、Skills、Sessions 和代理。

支持哪些工具

README 中列出的核心支持对象包括五类：

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

这几个工具本身定位相近，都是围绕 AI 编程、Agent 工作流和命令行协作展开。但它们的配置体系不同，CC Switch 的价值就在于把这些差异包装起来。

对经常比较不同 AI 编程工具的人来说，这比每次手动翻配置文件省心很多。

Provider 管理

CC Switch 的第一层能力是 Provider 管理。

它内置了 50 多个 Provider 预设，README 中提到的方向包括 AWS Bedrock、NVIDIA NIM，以及各种社区 relay。用户可以复制 API key，一键导入，然后在界面中切换。

实用点主要有几个：

一键添加 Provider。
Provider 拖拽排序。
系统托盘快速切换。
Provider 导入和导出。
部分通用 Provider 可同步到多个应用。

对很多人来说，这个功能已经足够有吸引力。因为 AI 编程工具的日常使用，经常不是“模型不会用”，而是“今天这个 key 用哪个工具、哪个 endpoint、哪个账号”容易乱。

本地代理与故障切换

除了写配置文件，CC Switch 还提供本地代理模式。

这个能力的重点是：

热切换 Provider。
格式转换。
自动故障转移。
熔断器。
Provider 健康检查。
请求修正。

简单说，它不只是把配置写进目标工具，还可以在中间加一层本地代理，让不同工具通过代理访问模型服务。

这对多 Provider 用户很有用：一个服务挂了，可以切到另一个；一个模型贵，可以换成更便宜的；某个请求格式不兼容，也可以通过代理层做适配。

MCP、Prompts 和 Skills

CC Switch 比较重要的第二层能力，是统一管理 MCP、Prompts 和 Skills。

MCP

它提供统一 MCP 面板，可以在多个应用之间管理 MCP server，并支持双向同步和 Deep Link 导入。

这对正在用 MCP 的用户很实用。因为 MCP server 一多，配置很容易分散在不同客户端里。统一面板可以减少重复配置，也方便迁移。

Prompts

Prompts 部分支持 Markdown 编辑，并且可以在不同工具之间同步对应文件，例如：

CLAUDE.md
AGENTS.md
GEMINI.md

这些文件本质上都是给 Agent 的项目说明书。统一管理后，可以更容易维护团队规则、项目约定和全局提示。

Skills

Skills 支持从 GitHub 仓库或 ZIP 文件一键安装，也支持自定义仓库管理、符号链接和文件复制。

如果你同时使用 Claude Code、Codex、OpenClaw 这类工具，Skills 很容易变成一堆散落在不同目录的文件。CC Switch 把它们集中起来，能降低维护成本。

会话与工作区

README 还提到 Session Manager 和 Workspace 相关能力。

它可以浏览、搜索和恢复多个应用里的会话历史。对长期使用 AI 编程工具的人来说，会话管理其实很重要：很多有价值的上下文、调试过程、方案比较，都埋在旧对话里。

此外，它还为 OpenClaw 提供 Workspace editor，可以编辑 AGENTS.md、SOUL.md 等 agent 文件，并带 Markdown 预览。

这说明 CC Switch 不只是一个“切换 key 的小工具”，而是在往 AI Agent 工作台方向扩展。

云同步与数据存储

CC Switch 支持通过 Dropbox、OneDrive、iCloud、NAS 或 WebDAV 同步 Provider 数据。

本地数据存储方式也比较清楚：

数据库：~/.cc-switch/cc-switch.db
本地设置：~/.cc-switch/settings.json
自动备份：~/.cc-switch/backups/
Skills：~/.cc-switch/skills/
Skill 备份：~/.cc-switch/skill-backups/

它使用 SQLite 作为主要数据源，并强调原子写入和自动备份，目标是避免配置文件在切换或写入时损坏。

这个设计对重度用户很关键。因为一旦配置管理工具本身把配置写坏，影响的是所有 AI 编程工具。

安装方式

CC Switch 是跨平台桌面应用，基于 Tauri 2 构建。

系统要求大致如下：

Windows：Windows 10 及以上
macOS：macOS 12 Monterey 及以上
Linux：Ubuntu 22.04+、Debian 11+、Fedora 34+ 等主流发行版

Windows 用户可以下载 .msi 安装包或便携版压缩包。

macOS 用户可以用 Homebrew：

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

更新：

`1`	`brew upgrade --cask cc-switch`

Linux 用户可以选择 .deb、.rpm 或 AppImage。Arch Linux 用户也可以通过 paru -S cc-switch-bin 安装。

截至 2026 年 5 月 6 日，仓库页面显示最新 release 为 CC Switch v3.14.1，发布时间是 2026 年 4 月 23 日。

技术栈

从仓库结构看，CC Switch 是典型的 Tauri 桌面应用：

前端：React 18、TypeScript、Vite、TailwindCSS、TanStack Query、shadcn/ui
后端：Tauri 2、Rust、SQLite、Tokio
测试：Vitest、MSW、Testing Library

核心设计模式包括：

SQLite 作为 Single Source of Truth。
JSON 保存设备级本地设置。
切换时写入目标工具的 live config。
编辑当前 Provider 时从 live config 回填。
使用临时文件加 rename 的方式做原子写入。
数据库连接加锁，避免并发写入问题。

这类架构说明项目并不是简单脚本，而是按长期桌面工具来设计的。

适合谁用

CC Switch 适合下面几类用户：

同时使用 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw。
经常切换官方账号、第三方 relay、本地模型或团队 Provider。
已经开始大量使用 MCP。
想统一维护 CLAUDE.md、AGENTS.md、GEMINI.md。
经常安装、测试和迁移 Skills。
想看不同工具的会话历史和使用情况。

如果你只用一个 AI 编程工具，而且一直走官方登录，不怎么折腾 Provider、MCP 和 Skills，那它的价值可能没那么明显。

但如果你已经进入“多工具、多账号、多 Provider、多项目”的状态，它能省掉很多琐碎配置工作。

需要注意什么

这类工具很方便，但也要注意边界。

第一，它会管理多个 AI CLI 的配置，因此要确认自己信任这个工具和它的写入逻辑。

第二，API key、relay endpoint、MCP server 都属于敏感配置。开启云同步前，要确认同步目录和 WebDAV 服务本身安全可靠。

第三，切换 Provider 后，多数工具仍然需要重启终端或 CLI 才能生效。README 中提到，Claude Code 对 Provider 数据支持热切换，但其他工具通常仍需要重启。

第四，切回官方登录时，最好按项目说明添加 official provider，再重新走对应工具的登录流程。

小结

CC Switch 的价值不在于又做了一个 AI 编程工具，而在于它承认了一个现实：AI 编程生态已经进入多工具并存阶段。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 各有自己的配置系统，MCP、Skills、Prompts、Provider 又在快速扩展。继续靠手动改配置，迟早会变成负担。

CC Switch 把这些东西收进一个桌面应用里，让用户可以更轻松地切换 Provider、同步 MCP、管理 Skills、维护提示文件和查看会话。对重度 AI 编程用户来说，这类工具很可能会从“可选小工具”变成“日常基础设施”。

参考资料

farion1231/cc-switch

Codex App 保姆级上手：安装、沙盒、并行任务、Skills 与 MCP

Wed, 06 May 2026 08:41:17 +0800

Codex App 可以理解成一个面向 AI 编程的任务工作台。它不是传统 IDE，也不是单纯聊天窗口，而是把多任务、项目管理、沙盒权限、Git、云端运行、插件、Skills、MCP 和自动化集中到一个界面里。

如果你已经在用 Codex CLI、Claude Code、Cursor 或其他 coding agent，Codex App 最值得关注的地方，是它把“多个 agent 并行干活”做成了一个更清晰的桌面工作流。

Codex App 适合做什么

Codex App 的核心价值不是让 AI 回答问题，而是让 AI 在项目目录里持续执行任务：

修改代码、运行命令、启动开发服务。
管理多个项目和多个任务。
在本地或云端执行长任务。
调用插件、Skills 和 MCP 扩展能力。
通过 Git、worktree 和 PR 管理改动。

OpenAI 官方也把 Codex App 定位成一个用于管理多个 coding agent 的界面。它适合需要同时推进多个代码任务的人，尤其适合前端页面、脚本工具、小型应用、文档整理和自动化工作流。

安装前准备

使用 Codex App 前，建议先准备好三个基础工具：

Git
Node.js
VS Code 或你常用的 IDE

Codex App 支持 macOS 和 Windows。安装后使用 ChatGPT 账号登录，首次进入时可以选择主要使用场景，例如编程或日常工作。Codex 会根据选择预装一部分插件和 Skills，后续也可以在设置和插件市场里调整。

Windows 和 macOS 的主要功能大体一致，但部分电脑自动化能力可能依赖具体平台和插件支持，实际以你当前版本显示为准。

界面结构：项目、任务和对话

Codex App 是典型的三栏布局：

左侧：项目、任务、历史对话、插件和自动化入口。
中间：当前对话窗口。
右侧：文件、浏览器、终端、运行结果等多功能区域。

一个项目通常对应一个本地文件夹。你可以在同一个项目里开多个对话，也可以同时打开多个项目，让不同 agent 并行执行任务。

任务列表会显示不同状态：

正在运行：agent 仍在执行。
等待批准：需要你确认权限、联网、安装依赖或执行高风险操作。
已完成：任务已经结束，可以查看结果或继续追问。

这比在多个终端窗口里来回切换更直观，也更适合同时管理多个 AI 任务。

沙盒与权限控制

Codex App 的权限体系围绕沙盒展开。默认情况下，当前项目文件夹会成为 agent 的主要工作范围。

常见权限边界包括：

可以读取和修改项目目录内的文件。
默认不能随意修改项目外文件。
默认会限制联网或高风险命令。
需要越权时，会向用户申请批准。

比较实用的模式是“自动审查”：低风险操作由系统自动放行，高风险操作再交给用户确认。这样既能减少频繁弹窗，又能避免 agent 在不知情的情况下执行危险操作。

“完全访问”要谨慎开启。它适合你明确知道 agent 要做什么，并且项目已经有 Git 备份、重要文件也有额外备份的场景。日常使用不建议长期保持完全访问。

上下文、模型和额度

Codex App 会显示当前对话的上下文使用情况。对话越长，历史内容越多，模型需要处理的上下文也越大。

实用建议是：

一个任务完成后，优先开新对话。
长对话可以手动压缩，但不要把压缩当成万能记忆。
复杂任务先写清楚目标、边界和验收标准。
不要把大量无关日志、报错和文件一次性塞进对话。

模型选择上，可以根据任务复杂度调整思考强度。简单修改、文案整理、重复任务不一定需要最高规格模型；架构迁移、疑难 bug、跨文件重构则更适合使用更强模型。

如果界面里有快速模式，也要注意它通常会带来更高的额度消耗。赶时间时可以开，日常不必默认开启。

图片生成与多模态输入

Codex App 可以接收图片和文件作为上下文，也可以在合适场景中调用图像生成能力。

这对前端和内容类项目很有用。例如你可以让 Codex：

根据截图修正页面样式。
替换网页中的不合适配图。
生成产品图、轮播图或页面素材。
根据 UI 截图指出需要修改的位置。

更高效的用法是：不要只说“改好看一点”，而是结合截图指出具体问题，例如“这个卡片间距太大”“这里的图和服务场景不匹配”“把地图区域做得更清楚”。

Steer：任务执行中及时纠偏

Steer 可以理解成“执行中接管方向”。当 agent 已经开始执行，但你发现它理解错了方向，不应该等它全部跑完再改。

这时可以使用引导功能，把新的指令插入当前执行流程，让 Codex 及时修正路线。

适合使用 Steer 的场景包括：

agent 误解了需求。
生成的页面风格明显不对。
正在执行的方案成本太高。
你临时补充了关键约束。

一般建议保留默认排队行为，只在确实需要干预时手动使用 Steer。这样既不会打乱正常任务，也能在关键时刻把方向拉回来。

计划模式和内置浏览器

复杂任务建议先开计划模式。计划模式下，Codex 不会马上改代码，而是先输出方案，必要时还会用卡片形式追问关键选择。

适合开计划模式的任务：

框架迁移，例如从普通 React 项目迁到 Next.js。
大范围重构。
涉及数据库、认证、部署的功能。
你还没想清楚技术路线的需求。

Codex App 的右侧区域可以打开内置浏览器，用来预览本地开发服务。你可以在页面上做批注，让 Codex 按具体 UI 位置修改问题。这种“看页面、点位置、让 AI 改”的流程，比纯文字描述更适合前端调试。

Git、IDE 和代码回滚

Codex App 不是完整 IDE。它可以查看代码、批注代码，但真正的手写编辑仍然更适合交给 VS Code、Cursor、Windsurf 等 IDE。

建议每个 Codex 项目都尽早初始化 Git：

让 Codex 创建或检查 .gitignore。
在完成一个可用状态后提交一次。
每次大改前确保有干净提交点。
不满意时用 Git 回滚代码。

如果只回滚对话历史，代码不会自动跟着回滚。比较稳的做法是：对话层面回到合适节点，代码层面用 Git commit hash 回到对应状态。

Worktree：并行开发多个方向

git worktree 是 Codex App 里非常适合并行 agent 的能力。

它的本质是：基于同一个仓库创建多个独立工作目录，每个目录对应不同分支。这样你可以让不同 agent 在不同文件夹里同时开发，不互相覆盖。

典型用法：

一个 worktree 优化客户评价组件。
一个 worktree 调整门店信息和地图布局。
两个任务完成后分别合并回主干。
合并完成后删除临时 worktree。

这比在同一个目录里让多个 agent 同时改代码稳得多。遇到冲突时，也可以按正常 Git 流程 review 和合并。

云端运行环境

Codex 不只能在本机工作，也可以把任务委托到云端环境执行。

云端运行适合这些场景：

出门在外，手边只有手机。
希望 agent 在后台跑长任务。
代码已经同步到 GitHub，需要让 Codex 基于远端仓库修改。
希望通过 PR 形式审查和合并改动。

典型流程是：先把本地代码推到 GitHub，再让 Codex 在云端环境中拉取仓库、执行任务、生成改动，最后以 PR 或 diff 的方式交给你审核。

本地继续开发时，要记得把远端最新改动同步回来。

记忆系统：写好 AGENTS.md

新对话默认没有完整历史记忆。项目一复杂，如果每次都重新解释背景，会很浪费。

最通用的做法，是在项目根目录维护 AGENTS.md。这个文件可以记录：

项目目标和主要技术栈。
常用命令。
目录结构说明。
代码风格和命名约定。
禁止事项，例如不要批量删除文件。
测试、构建和部署规则。

你也可以让 Codex 先通读项目，再生成一版 AGENTS.md，然后人工审一遍。复杂项目里，这个文件非常值得维护。

全局规则也要谨慎。适合写入所有项目都通用的安全约束，例如“不要递归删除目录”“执行破坏性操作前必须确认”。不要把某个项目的细节写进全局规则，否则会污染其他项目。

插件和自动化

插件用于把外部服务接入 Codex，例如 GitHub、Gmail、Google Drive、数据库、部署平台等。

插件的价值在于减少复制粘贴。比如你可以让 Codex：

查看某个 GitHub 仓库的 star 趋势。
整理邮件内容并发给自己。
定期执行某个检查任务。
把结果写成摘要。

自动化则适合重复任务。例如每周五下午检查一次仓库数据，并发送邮件报告。简单自动化任务通常不需要最高规格模型，选择较轻量的模型即可。

Skills：把工作流变成可复用能力

Skills 是 Codex 的“专业说明书”。它不是单次提示词，而是把某类任务的流程、规范、脚本和注意事项沉淀下来，让 Codex 后续稳定复用。

常见来源有三类：

官方 Skills。
第三方 Skills。
自己编写的 Skills。

适合做成 Skill 的工作：

把字幕整理成图文笔记。
按公司规范写周报。
批量处理图片或文档。
固定格式的代码审查。
特定框架的项目初始化。

如果某个提示词你已经复制粘贴了很多次，就值得考虑把它做成 Skill。

MCP：接入外部工具和数据库

MCP 可以理解成给大模型使用的标准化工具协议。通过 MCP，Codex 可以调用外部服务完成更具体的任务。

例如接入 Supabase 后，可以让 Codex：

创建数据表。
读取数据库结构。
修改后端接口。
把前端表单提交到数据库。
根据数据库状态调试问题。

这类能力很强，但也要注意权限边界。数据库、生产环境、部署平台、邮件账号都属于高风险资源。第一次接入时，最好使用测试项目和低权限账号。

部署插件

部署平台插件可以让 Codex 直接完成构建和发布，例如把前端项目部署到 Netlify 一类平台。

这类插件适合小型网站、原型页面、内部工具和展示项目。实际使用时建议注意：

部署前先跑本地构建。
环境变量不要直接写进代码。
发布后检查页面是否能正常访问。
生产项目要保留人工 review。

AI 可以帮你打通发布流程，但发布权限仍然要谨慎管理。

电脑自动化

在支持的平台和插件环境里，Codex 还可以操作浏览器或桌面应用，完成更接近 RPA 的任务。

例如：

打开聊天软件并准备一条消息。
浏览项目看板，汇总任务状态。
生成英文简报。
在你确认后发送给指定对象。
把这套流程做成定时自动化。

这类功能很有想象力，但也最需要安全边界。凡是涉及发消息、发邮件、提交表单、付款、删除数据的操作，都应该保留人工确认。

使用建议

Codex App 的正确打开方式，不是让它一次性全自动接管一切，而是把任务拆清楚，让它在受控环境里高效执行。

推荐习惯：

每个项目先初始化 Git。
复杂任务先开计划模式。
并行任务优先用 worktree。
项目规则写进 AGENTS.md。
高风险操作保留人工确认。
重复流程沉淀成 Skill 或自动化。
插件和 MCP 先在测试环境验证。

参考资料

小结

Codex App 的重点不是“多一个 AI 聊天窗口”，而是把 AI 编程变成一个可管理的工作台：本地项目、云端任务、Git、worktree、插件、Skills、MCP 和自动化都能串起来。

真正用好它的关键，是在“放权”和“控制”之间找到平衡。小任务可以大胆交给 Codex，复杂任务先让它计划，高风险动作必须确认。这样它才会从一个会写代码的助手，变成可以长期协作的工程工具。

Claude for Creative Work：Anthropic 把 Claude 接进 Adobe、Blender、Ableton 和 SketchUp

Fri, 01 May 2026 05:52:14 +0800

Anthropic 在 2026 年 4 月 28 日发布了 Claude for Creative Work，重点不是再讲一个新的聊天机器人，而是把 Claude 接进创意行业已经在用的软件里。

这次合作名单很有代表性：Blender、Autodesk、Adobe、Ableton、Splice，还包括 Affinity by Canva、Resolume、SketchUp 等工具生态。

简单说，Anthropic 想做的是：让 Claude 不只在聊天框里给建议，而是进入设计、3D、音乐、视频和现场视觉这些具体工作流。

Claude 不能替代审美，但可以替代很多苦活

Anthropic 在公告里的态度比较克制：Claude 不能替代创作者的品味和想象力。

这个判断是对的。创意工作的关键往往不是“生成一个东西”，而是判断哪个方向值得继续、哪个细节需要保留、哪个方案符合项目气质。

但创意流程里也有大量重复劳动：

批量调整图片
给图层改名
导出不同格式文件
整理素材
查软件文档
写脚本改场景
在多个工具之间转换格式
把一个想法快速做成可看的草稿

这些环节不一定需要“灵感”，但很消耗时间。Claude 的作用更像是把创作者从这些机械步骤里释放出来。

Connectors 是这次的核心

这次发布的关键是 connectors。

connectors 可以理解为 Claude 连接外部平台和软件的桥。用户不是把需求复制到 Claude，再手动回到软件里操作，而是让 Claude 直接理解工具、调用能力或读取相关文档。

Anthropic 公告里提到的连接方向包括：

Ableton：让 Claude 基于 Live 和 Push 的官方文档回答问题。
Adobe for creativity：连接 Creative Cloud 中的 50 多个工具，覆盖 Photoshop、Premiere、Express 等。
Affinity by Canva：自动化专业创意工作流里的重复生产任务，例如批量图片调整、图层重命名和文件导出。
Autodesk Fusion：让有 Fusion 订阅的设计师和工程师通过对话创建和修改 3D 模型。
Blender：通过自然语言使用 Blender 的 Python API，帮助理解复杂场景、访问文档和扩展功能。
Resolume Arena 和 Resolume Wire：让 VJ 和现场视觉艺术家用自然语言实时控制 Arena、Avenue 和 Wire。
SketchUp：把与 Claude 的对话变成 3D 建模起点，例如描述房间、家具或场地概念，再到 SketchUp 里继续细化。
Splice：让音乐制作人直接从 Claude 里搜索免版税采样库。

这些集成覆盖了设计、音频、3D、视频、现场演出和工程建模。它们不是一个方向的小实验，而是 Anthropic 明确在往“创意软件工作台”走。

对创意工作有什么用

从公告看，Claude 在创意工作里的用途可以分成几类。

第一类是学习复杂工具。

很多创意软件很强，但学习曲线也很陡。Blender、Ableton、Fusion、Premiere 都是典型例子。用户可以让 Claude 解释某个 modifier stack、讲一个合成技巧、演示某个陌生功能，而不是在搜索结果、论坛和官方文档之间来回跳。

第二类是写脚本和插件。

创意软件都有大量可自动化空间。Claude Code 可以帮用户写脚本、插件、shader、程序化动画或参数化模型。对会一点技术但不想一直查 API 的创作者来说，这个价值很实际。

第三类是打通工具链。

真实项目通常不是一个软件完成的。设计可能在 Adobe，3D 在 Blender 或 SketchUp，音频在 Ableton，素材来自 Splice，最后还要进入视频或演出系统。Claude 可以帮助转换格式、重组数据、同步素材，减少手工交接。

第四类是快速探索和交付。

Anthropic 还提到 Claude Design，这是 Anthropic Labs 的一个新产品，用于探索软件体验想法。它可以根据反馈迭代视觉方案，并且设计结果可以导出到其他工具，起点是 Canva。

第五类是减少重复生产工作。

比如批处理素材、搭建项目结构、批量调整场景对象、自动化导出。很多创作者并不是不会做，而是不想把一下午浪费在重复点击上。

Blender 是最值得注意的一环

这次公告里，Blender 的位置很特别。

Blender 是免费开源的 3D 创作套件，覆盖独立游戏、动效、建筑可视化、影视制作等场景。它本身就有强大的 Python API，也有大量复杂工作流。

Blender 开发者已经创建了一个 MCP connector，现在可以在 Claude 中正式使用。

这个连接器能做的事情包括：

分析和调试整个 Blender 场景
批量修改场景里的对象
使用 Blender Python API 写自定义脚本
把新工具直接加到 Blender 界面里
帮用户理解复杂设置和文档

更重要的是，Anthropic 加入了 Blender Development Fund，成为 Blender 项目的 patron，用来支持 Blender 继续发展 Python API。

这件事有两个信号。

第一，Anthropic 不只是想接入商业软件，也在押注开源创作工具。

第二，这个 connector 基于 MCP，理论上不只 Claude 能用，其他大模型也可以接入。这和 Blender 的开源与互操作方向比较一致。

这不是“AI 替代设计师”，而是“AI 进入工具层”

这次发布最值得关注的地方，不是 Claude 能不能生成一张图、一段音乐或一个 3D 模型。

更关键的是：AI 正在从聊天框进入工具层。

过去很多 AI 创作工具的体验是：

在 AI 工具里描述需求。
得到一个结果。
下载或复制出来。
回到专业软件里手动修改。

现在的方向更像是：

Claude 理解你的创意软件。
Claude 读取相关文档或项目上下文。
Claude 生成脚本、操作工具、整理素材或构建草稿。
创作者在熟悉的软件里继续判断和精修。

这对专业用户更有吸引力，因为他们不想离开原本的工具链，也不想把所有工作迁移到一个全新的 AI 平台。

对学生和创意教育的影响

Anthropic 也提到正在和艺术与设计项目合作，支持包含 creative computation 的课程。

首批项目包括：

Rhode Island School of Design 的 Art and Computation
Ringling College of Art and Design 的 Fundamentals of AI for Creatives
Goldsmiths, University of London 的 MA/MFA Computational Arts

学生和教师会获得 Claude 以及新 connectors 的访问权限，他们的反馈会帮助 Anthropic 理解创意实践者真正需要什么。

这点也很有意思。AI 创作能力如果只停留在“生成素材”，很容易变成炫技。但进入课程后，更重要的问题会变成：

学生如何理解工具背后的过程
如何把 AI 作为探索和原型工具
如何保留自己的判断力
如何用代码和自动化扩展创作边界
如何避免所有作品都变成同一种 AI 味道

这些问题比单纯讨论“AI 会不会取代创作者”更实际。

谁最适合关注这次发布

这次 Claude for Creative Work 对几类人尤其值得关注：

使用 Blender、SketchUp、Fusion 做 3D 建模的人
使用 Adobe、Affinity 做设计和视频生产的人
使用 Ableton、Splice 做音乐制作的人
需要把多个创意工具串成工作流的人
会一点脚本，希望自动化创意软件的人
正在做创意教育、交互设计、计算艺术课程的人

如果只是偶尔让 AI 生成图片，这次发布未必马上改变体验。

但如果你已经在专业软件里工作，并且经常遇到“我知道要做什么，但这些步骤太繁琐”的情况，connectors 会很有价值。

需要注意的边界

这类工具也不是万能的。

第一，Claude 仍然需要用户判断结果是否符合审美、品牌和项目目标。

第二，自动化操作专业软件时，最好从小范围任务开始，不要一上来就让它批量修改不可恢复的项目文件。

第三，连接器质量很关键。如果 connector 只能查文档，和能真实操作软件，是两种完全不同的体验。

第四，创意软件项目往往有复杂文件、素材依赖和版本管理。AI 参与之后，更需要备份和可回滚流程。

第五，版权、授权和素材来源仍然要自己把关。比如 Splice 强调的是 royalty-free samples，但实际项目使用时仍要确认具体授权条件。

小结

Claude for Creative Work 不是一次单点功能更新，而是 Anthropic 把 Claude 推进创意软件生态的一步。

它的重点不是让 Claude 变成创作者，而是让 Claude 成为创作者身边的工具助手：查文档、写脚本、批处理、连通软件、生成草稿、减少重复劳动。

真正有长期价值的地方，是 Claude 开始进入 Blender、Adobe、Ableton、SketchUp 这些创作者每天使用的环境里。

当 AI 不再只是一个单独网页，而是能理解和调用专业工具时，创意工作流会发生更实际的变化。

参考链接：

Claude for Creative Work - Anthropic

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 编程助手才更容易按项目规则做事。

Prompt Optimizer：开源提示词优化、测试与 MCP 工具

Fri, 01 May 2026 03:09:07 +0800

Prompt Optimizer 是一个开源的提示词优化工具，目标很直接：帮助你把一段粗糙的提示词改得更清晰、更稳定，也更容易被大语言模型执行。

它不只是一个“帮我润色 prompt”的页面。项目同时提供提示词优化、结果测试、对比评估、多模型接入、图像生成提示词处理，以及 MCP 集成。对经常写系统提示词、用户提示词、AI 工作流模板的人来说，它更像一个专门用来打磨提示词的工作台。

它解决什么问题

很多人使用 AI 时都会遇到类似问题：

提示词越写越长，但模型输出没有明显变好
同一个需求换个模型就表现不稳定
系统提示词和用户提示词混在一起，很难拆开调试
改了一版 prompt，不知道是不是真的比上一版更好
想复用变量模板，但每次都要手动替换和测试
想把提示词优化能力接入其他 AI 工具，却缺少标准接口

Prompt Optimizer 主要围绕这些问题设计。它把“写 prompt”拆成优化、测试、评估、对比、迭代几个环节，让提示词不再只靠感觉调整。

主要功能

1. 优化系统提示词和用户提示词

提示词并不只有一种。

系统提示词通常负责定义角色、目标、边界、输出规范和工作方法；用户提示词则更接近一次具体任务的输入。两者混在一起时，模型容易抓不住重点，后续复用也困难。

Prompt Optimizer 支持系统提示词优化和用户提示词优化。你可以分别处理长期复用的角色设定，也可以处理某次具体任务的输入表达。

这对下面几类场景比较有用：

写 AI 编程助手的工作规则
写客服、审稿、翻译、分析类角色提示词
优化文生图提示词
把临时需求整理成可复用模板
为不同模型准备不同风格的 prompt

2. 测试和对比输出

只优化提示词还不够，关键是要知道优化后有没有变好。

项目支持分析、单结果评估、多结果对比评估。也就是说，你可以把原始提示词和优化后的提示词放到同一个任务里跑，看模型输出是否更准确、更稳定、更符合目标。

这比单纯“看起来更专业”的 prompt 更实用。因为很多提示词表面上写得完整，实际输出却可能更啰嗦、更僵硬，甚至把模型引向错误方向。对比测试能帮助你尽早发现这种问题。

3. 支持多模型

README 中提到项目支持 OpenAI、Gemini、DeepSeek、智谱 AI、SiliconFlow 等模型服务，也支持自定义 OpenAI 兼容接口。

这点很重要。提示词效果和模型强相关，同一段 prompt 在不同模型上的表现可能差别很大。多模型测试可以帮助你判断：

是提示词本身写得不好
还是某个模型不适合这个任务
是否需要为不同模型准备不同版本
小模型能否通过更清晰的提示词接近可用效果

如果你在本地使用 Ollama，或者公司内部有兼容 OpenAI 接口的模型服务，也可以通过自定义接口接入。

4. 高级测试模式

项目提供上下文变量管理、多轮会话测试和 Function Calling 支持。

变量管理适合模板化任务。比如你有一套闲置交易回复、商品描述、邮件回复、代码审查或文档生成提示词，只需要替换商品、价格、语气、目标用户等变量，就能快速测试不同输入下的表现。

多轮会话测试适合验证长期对话能力。很多 prompt 在单轮问答里看起来不错，一旦进入多轮追问，就会忘记约束、偏离角色或重复解释。多轮测试可以更接近真实使用场景。

Function Calling 支持则适合更工程化的 AI 应用。它能帮助你验证模型在工具调用、参数生成和结构化输出上的表现。

5. 图像生成提示词

Prompt Optimizer 也支持文生图和图生图相关能力，README 中提到集成 Gemini、Seedream 等图像模型。

文生图提示词的优化重点和文本任务不同。它更关注主体、构图、空间关系、风格、材质、光线、情绪和限制条件。把一句很模糊的想法拆成更可控的视觉描述，通常比单纯加长提示词更有价值。

如果你经常需要生成产品图、封面、插画、主视觉或风格参考图，这类优化会比较实用。

使用方式

项目提供多种入口：

在线版本
Vercel 自部署
桌面应用
Chrome 插件
Docker 部署
Docker Compose 部署
MCP Server

在线版本适合快速体验。项目说明中提到它是纯前端应用，数据存储在浏览器本地，并直接与 AI 服务商交互。

桌面应用适合需要直接连接各种模型 API 的用户。浏览器环境容易遇到跨域限制，桌面应用可以绕过这类问题，尤其适合连接本地 Ollama 或一些跨域策略严格的商业 API。

Docker 部署适合放在自己的服务器或内网环境里使用。README 给出的基础命令如下：

`1`	`docker run -d -p 8081:80 --restart unless-stopped --name prompt-optimizer linshen/prompt-optimizer`

如果要配置 API 密钥和访问密码，可以通过环境变量传入：

docker run -d -p 8081:80 \
  -e VITE_OPENAI_API_KEY=your_key \
  -e ACCESS_USERNAME=your_username \
  -e ACCESS_PASSWORD=your_password \
  --restart unless-stopped \
  --name prompt-optimizer \
  linshen/prompt-optimizer

国内访问 Docker Hub 较慢时，项目也提供了阿里云镜像地址，可按 README 中的说明替换镜像名。

MCP 能做什么

Prompt Optimizer 支持 Model Context Protocol，也就是 MCP。

通过 Docker 运行时，MCP 服务可以和 Web 应用一起启动，并通过 /mcp 路径访问。这样它就不只是一个网页工具，而是可以被 Claude Desktop 等支持 MCP 的应用调用。

README 中列出的 MCP 工具包括：

optimize-user-prompt：优化用户提示词
optimize-system-prompt：优化系统提示词
iterate-prompt：对已有提示词做定向迭代

这类接口很适合放进 AI 工作流里。比如你在写复杂任务提示词时，可以让支持 MCP 的客户端直接调用提示词优化能力，而不必每次打开网页手动复制。

和普通聊天工具有什么区别

普通聊天工具当然也能帮你改 prompt，但它通常缺少几个环节：

不方便保存和对比多个版本
不方便同时测试多个模型
不方便把变量模板化
不方便做多轮会话验证
不方便接入 MCP 或部署到自己的环境

Prompt Optimizer 的价值在于把提示词优化做成一个可重复的流程。它不只是给你一版“看起来更完整”的文本，而是让你围绕实际输出持续调整。

适合谁使用

如果你符合下面几种情况，可以重点关注这个项目：

经常写系统提示词
经常为 AI 应用设计角色和输出格式
需要比较不同模型的输出效果
想把 prompt 做成可复用模板
需要测试多轮对话或工具调用
想把提示词优化能力接入 MCP 工作流
希望在本地或内网部署提示词工具

如果你只是偶尔问 AI 一个简单问题，用普通聊天页面就够了。这个工具更适合那些把提示词当成可维护资产的人。

使用时要注意什么

第一，不要把优化结果当成绝对正确。

提示词优化工具可以提高表达质量，但不能保证模型一定不会误解。重要任务仍然需要测试样例、人工检查和版本对比。

第二，不要只追求更长。

好的 prompt 不一定更长。它应该更清晰地表达目标、边界、输入输出格式和判断标准。无意义的规则堆叠反而会让模型抓不住重点。

第三，要按模型调 prompt。

不同模型对角色设定、格式约束、推理步骤和示例的敏感度不同。一个在大模型上表现很好的提示词，不一定适合小模型。多模型测试正是这个工具值得使用的原因之一。

第四，部署时要考虑密钥和访问控制。

如果你把它部署到公网，应该配置访问密码，并谨慎处理 API key。项目支持通过环境变量配置访问控制，不要把敏感配置直接写到公开仓库里。

参考

linshenkx/prompt-optimizer

最后一句

Prompt Optimizer 适合用来把提示词从“临时手写的一段话”整理成“可以测试、可以比较、可以迭代的工作资产”。

当你开始在多个模型、多个场景、多个版本之间维护 prompt 时，这类工具会比普通聊天窗口更顺手。

AI 名词解释：用大白话讲清楚 Agent、MCP、RAG 和 Token

Thu, 23 Apr 2026 13:13:40 +0800

刚开始接触 AI，最容易劝退人的通常不是模型本身，而是讨论里那些一串串名词。Agent、MCP、RAG、AIGC、Token 看起来都很常见，但如果没人先用人话讲一遍，很多人其实只是在“眼熟”，并没有真正听懂。

这篇就顺着一组常见入门解释的思路，把 10 个高频 AI 名词压缩成一套更容易记住的解释。目标不是讲得多学术，而是先帮你建立一个能跟上日常讨论的基础框架。

10 个常见 AI 名词，分别是什么意思

1. Agent：不只会聊天的执行型 AI

Agent 可以先理解成“会干活的 AI 助手”。

普通聊天机器人更像是你问一句、它答一句；Agent 则更进一步，它会把任务拆开、安排步骤、调用工具，再把结果交回来。比如你让它帮你整理资料、查信息、生成文档，它不只是给建议，而是可能直接把这些动作串起来做完。

所以 Agent 的关键，不在“会不会说”，而在“能不能做”。

2. OpenClaw：驻留在电脑里的 AI 助手

视频里把 OpenClaw 形容成一种“住在电脑里的 AI 管家”。

你可以把这类工具理解成更贴近桌面操作的 AI 助手：它不只是接收文字，还可能直接观察界面、调用本地工具、按流程执行任务。和普通网页聊天相比，这类工具更强调实际操作能力。

如果说 Agent 是抽象层面的“执行型 AI”，那这类桌面型助手更像是它在个人电脑上的一种具体落地形式。

3. Skills：给 Agent 装上的能力包

Skills 可以理解成 Agent 的功能模块或操作说明。

同一个 Agent，装上不同的 Skills，就能表现出不同的专长。比如有的偏文案生成，有的偏数据整理，有的偏代码处理。它们有点像手机里的 App，也有点像一套套可复用的工作流程。

所以很多时候，不是模型突然“变聪明”了，而是它背后多了一组明确的规则、工具和步骤。

4. MCP：AI 连接外部工具的统一接口

MCP 全称是 Model Context Protocol。

如果用生活里的比喻，它有点像 AI 世界里的 Type-C 接口。以前模型想接不同工具，往往要一套一套单独对接；有了统一协议之后，接入方式会更标准，也更容易复用。

对普通用户来说，最值得记住的一点是：MCP 解决的不是“模型会不会回答”，而是“模型怎么安全、稳定地连上外部工具和资源”。

5. 抽卡：AI 生成结果带有随机性

“抽卡”这个说法常见于 AI 绘图、视频生成和内容创作场景。

意思很简单：同样的提示词、同样的大方向，每次生成出来的结果也可能不一样。有时候效果惊艳，有时候明显翻车，所以很多人会把反复尝试生成结果这件事，形容成像游戏里抽卡。

它提醒我们的其实是同一件事：AI 生成不是固定公式，而是带概率和波动的过程。

6. API：应用和模型之间的连接方式

API 全称是 Application Programming Interface，也就是应用程序接口。

它可以理解成程序之间沟通的标准入口。你在自己的应用、脚本或编辑器里调用模型服务，本质上就是通过 API 发请求、拿结果。

如果把模型服务比作一家餐厅，那么：

菜单像 API 文档
点菜像发起 API 请求
后厨出餐像模型返回结果

所以很多工具表面上看起来不一样，底层其实都是在调用某种 API。

7. 多模态：AI 不只处理文字

“多模态”说的是 AI 不再只会读写文本，而是可以同时处理多种信息形态。

比如它可以看图、听语音、理解视频、生成图片，甚至做实时语音和视频交互。和早期只会处理文字的模型相比，多模态模型更像是在同时拥有“看、听、说、写”的能力。

这也是为什么现在很多 AI 产品的交互方式，已经不再局限于一个输入框。

8. RAG：先检索资料，再组织答案

RAG 是 Retrieval-Augmented Generation，通常译作检索增强生成。

它适合解决一个很现实的问题：模型本身的训练数据有时间边界，也不知道你企业内部的新文档、客服记录和业务规则。RAG 的思路就是，先从指定资料里把相关内容找出来，再结合这些资料生成回答。

它的价值通常体现在三点：

答案更容易贴近真实资料
可以追溯回答依据来自哪里
新文档加入后，知识可随时更新

所以很多企业知识库、智能客服和内部问答系统，底层都会用到 RAG。

9. AIGC：AI 生成内容的总称

AIGC 是 AI Generated Content 的缩写。

它不是某一个单独工具，而是一个总称，泛指 AI 生成出来的内容，包括文本、图片、音频、视频等各种形式。你看到的 AI 写稿、AI 制图、AI 做短视频、AI 配音，都可以放进 AIGC 这个大框里理解。

这个词真正重要的地方在于，它描述的是一种内容生产方式，而不是某个具体模型。

10. Token：模型处理内容时的计量单位

Token 可以理解成模型处理文本时使用的基础计量单位。

它不完全等于“一个字”或者“一个单词”，但在使用层面上，你可以先把它当成模型计算和计费时的通用单位。你的输入会消耗 Token，模型的输出会消耗 Token，上下文里保留的历史内容同样会占用 Token。

所以为什么很多模型服务都在强调上下文长度、成本控制和压缩提示词，本质上都和 Token 有关。

Claude Code 额度省着用：模型选择、上下文、缓存与 /compact

Sun, 19 Apr 2026 15:26:56 +0800

最近很多人在用 Claude Code 或 Claude Max 时会遇到一个问题：明明买了 Pro、Max 5x，甚至 Max 20x，结果没跑多久就提示额度快满，或者直接需要等重置。尤其是在大项目里让 Claude Code 读很多文件、修复杂 bug、跑长任务时，这种感觉会更明显。

这里先说结论：额度不是按“时间”线性扣的，而是和模型、上下文长度、附件、代码库规模、对话历史、工具调用和当前容量都有关系。同样 5 小时窗口，有的人能用很久，有的人十几分钟就耗尽，通常不是账号坏了，而是每次请求都太重。

这篇整理一套比较实用的省额度习惯。

01 先理解 Claude 的用量窗口

Claude Pro 和 Max 都有使用限制，Claude Code 的使用量会和 Claude 网页、桌面、移动端共享同一套订阅额度。官方说明里提到，消息数量会受到消息长度、附件大小、当前对话长度、所用模型或功能影响；Claude Code 还会受到项目复杂度、代码库大小、自动接受设置等影响。

大致可以这样理解：

Pro：适合轻量使用和小项目。
Max 5x：适合更频繁使用和较大的代码库。
Max 20x：适合更重度、日常高频协作。
用量窗口按 5 小时会话重置。
长消息、长对话、大文件、复杂任务会更快消耗额度。
Opus 这类更强模型会比 Sonnet 更快触发限制。

所以“我只用了 20 分钟”这个说法不一定能说明问题。真正重要的是这 20 分钟里 Claude 读了多少上下文、用了什么模型、是否反复处理大文件、是否在同一个长对话里继续加任务。

02 第一件事：不要默认一直用最贵模型

Claude 系列里常见的定位是：

Opus：能力最强，适合复杂推理、架构决策、疑难 bug。
Sonnet：能力和成本比较均衡，适合大部分日常编码任务。
Haiku：更轻量，适合简单分类、摘要、格式转换等任务。

日常写脚本、改小 bug、整理文档、解释代码，大多数时候 Sonnet 已经够用。Opus 更适合留给这些场景：

复杂架构设计。
多文件深度重构。
难复现的 bug。
需要长链路推理的排障。
普通模型明显卡住的任务。

Claude Code 里可以用 /model 切换模型，也可以在 /config 里设置默认模型。比较稳的习惯是：默认 Sonnet，关键节点再切 Opus，而不是整场任务都用 Opus 扛。

03 第二件事：控制上下文，不要让旧任务拖着走

上下文越长，Claude 每次处理要看的内容越多，额度消耗也越高。Claude Code 官方文档明确建议主动管理上下文：

换到不相关任务时，用 /clear 清空历史。
当前任务做完一个阶段但还要保留重点时，用 /compact 压缩。
想知道上下文里什么占空间，用 /context。
想持续看到状态，可以配置 status line。

一个好用的节奏是：

小阶段完成：/compact
大任务结束：/clear
切换无关项目：/clear
上下文接近很高占用：提前 /compact

/compact 会把前面的对话压成摘要，保留关键任务状态、结论、文件路径、待办事项，但减少后续每次请求要携带的历史。你也可以给它补一句重点：

`1`	`/compact 保留已修改文件、测试结果、剩余待办和关键设计决策`

不要等自动压缩才处理。官方文档提到，Claude Code 会在上下文接近容量上限时自动压缩，但手动在阶段边界压缩，通常更可控。

04 第三件事：长对话和大文件会让每次请求变贵

很多人以为“我只是继续问一句”，应该很便宜。但在长对话里，这一句背后可能带着大量历史、文件摘要、工具定义和系统规则。

特别容易涨上下文的东西包括：

一直不清理的长对话。
让 Claude 读完整大文件。
贴很长日志、构建输出、测试输出。
一次性塞很多截图或图片。
让它反复扫描整个仓库。
过长的 CLAUDE.md。
开了很多 MCP server。

比较省的做法是：日志只贴关键报错，测试输出只给失败部分，大文件让它先用 rg、head、tail、符号搜索定位，再读必要片段。能用命令行过滤的内容，不要整包塞进上下文。

05 第四件事：理解缓存，但不要迷信缓存

Anthropic 的 Prompt Caching 会缓存重复的 prompt 前缀。默认缓存生命周期是 5 分钟，也支持 1 小时缓存。缓存命中时，重复的大段上下文不需要完整重新处理，有助于降低成本和改善额度利用。

但缓存有几个限制：

需要内容完全匹配，文字和图片都要一致。
默认缓存是短生命周期。
改模型、改工具、改系统提示、改上下文结构，都可能降低命中。
输出 token 不会因为缓存而消失，该生成的回答仍然要生成。
Claude Code 具体如何利用缓存，是产品层实现细节，不要把它当成永远稳定的“免费记忆”。

实际使用里，最重要的不是研究缓存细节，而是保持会话稳定：

同一阶段尽量别频繁切模型。
不要中途反复改大量规则。
不要在同一任务里不停贴新图片。
长任务中间不要闲置太久后又继续塞大请求。
阶段结束主动 /compact。

这样更容易让重复上下文保持可复用，也能降低后续请求负担。

06 关于高峰时段：能避开就避开，但不要当固定公式

网上常有人说某些时段额度会更紧。官方帮助中心的表述更谨慎：可发送数量会受到 Claude 当前容量、对话长度、附件、模型和功能影响。也就是说，高峰容量确实可能影响体验，但不要把某个地区的某个时间段当成永久固定规则。

实用建议是：

大重构、大批量分析尽量放到自己网络和服务都稳定的时段。
不要在快到休息时开启一个超长任务。
预计会离开很久时，先 /compact 或 /clear。
如果只是小改动，不要开 Opus 加长上下文硬跑。

这比记一个固定“几点到几点不能用”的规则更可靠。

07 精简 CLAUDE.md、rules、MCP 和 skills

Claude Code 会在会话中加载项目规则、工具信息和一部分环境上下文。官方文档也建议把通用规则和专用规则分开，避免每次启动都带着一大包不相关内容。

比较推荐的拆法：

CLAUDE.md：只放全局都适用的核心规则。
rules：放特定路径、特定文件类型才需要的规则。
skills：放特定工作流，例如发文章、部署、生成图片、提交代码。
MCP：只启用当前任务真的会用到的 server。

如果 CLAUDE.md 写了几百上千行，每次会话都要带进去。更好的方式是把“偶尔才用”的流程移到 skill 里，需要时再调用。

MCP 也是一样。工具多不等于效率高。Claude Code 文档提到可以用 /mcp 查看并禁用不需要的 server，也可以用 /context 看是什么占用了上下文空间。

08 实用指令清单

日常最常用的是这几个：

/model

切换模型。默认建议用 Sonnet，复杂推理再用 Opus。

/clear

清空当前上下文。换无关任务时用，最省。

`1`	`/compact`

压缩历史上下文。一个阶段完成但还要继续同一任务时用。

`1`	`/context`

查看上下文占用，排查是什么吃掉空间。

/status

查看当前订阅或额度相关状态。官方帮助中心也建议用它监控剩余额度。

/mcp

查看和管理 MCP server，关闭当前不用的工具。

如果你用 API 计费模式，还可以关注 /cost；但如果是 Pro/Max 订阅，官方文档说明 /cost 的美元估算不适合作为订阅账单依据，订阅用户更应该看 /stats 和 /status 这类使用信息。

09 一套省额度工作流

比较顺手的流程可以是这样：

新任务开始前先 /clear。
默认用 Sonnet。
先让 Claude 读项目结构和关键文件，不要一口气读全仓库。
每做完一个小阶段就 /compact。
复杂卡点再切 Opus。
日志、报错、测试输出先过滤再给。
任务完成后 /clear，不要拖着旧上下文开新活。
定期检查 CLAUDE.md、MCP 和 skills，把常驻上下文压小。

这个流程的核心是：让 Claude 每次只看当前真正需要看的东西。

10 小结

Claude Code 额度快速耗尽，通常不是单一原因，而是几个因素叠加：用了高成本模型、长对话一直不清、文件和日志塞太多、MCP 和规则常驻过重、缓存命中变差，再加上高峰容量波动。

省额度的核心也很简单：

日常任务优先 Sonnet。
Opus 留给真正复杂的问题。
阶段完成用 /compact。
换任务用 /clear。
用 /context 找上下文占用来源。
精简 CLAUDE.md、rules、MCP 和 skills。
不要把整仓库、整日志、整图片包都丢进去。

同样的 Pro 或 Max 方案，能做多少事，很大程度取决于你怎么管理上下文。把上下文变小、任务边界变清楚，Claude Code 的可用时间和稳定性都会明显好很多。

参考链接

Claude Help Center：Using Claude Code with your Pro or Max plan：https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Claude Help Center：About Claude’s Max Plan Usage：https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs：Manage costs effectively：https://code.claude.com/docs/en/costs
Anthropic Docs：Prompt caching：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching

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 值得放进工具箱。反过来，如果任务只是固定网站的低成本批量采集，传统爬虫或专用解析器仍然更合适。

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

抛弃 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 更适合作为连接协议，而不是唯一执行协议。