工作流 on KnightLi的博客

Personal AI Infrastructure：个人 AI 基础设施应该怎么搭

Sat, 06 Jun 2026 22:26:00 +0800

danielmiessler/Personal_AI_Infrastructure 是一个围绕个人 AI 基础设施的项目。它的描述很短：Agentic AI Infrastructure for magnifying HUMAN capabilities。重点不是做一个单点工具，而是把 AI、自动化、知识、流程和个人生产力放在同一个系统里考虑。

这类项目适合想认真打造个人 AI 工作台的人，而不是只偶尔用 ChatGPT 回答问题的人。

为什么需要个人 AI 基础设施

很多人使用 AI 的方式仍然很零散：

一个聊天窗口写文章；
一个插件总结网页；
一个脚本处理文件；
一个笔记软件存资料；
一个 Agent 改代码；
一堆 prompt 散落各处。

问题是，这些工具之间没有形成系统。资料、偏好、任务、自动化和输出结果互不相通，AI 很难真正长期放大你的能力。

个人 AI 基础设施要解决的，就是把这些碎片连成一套可持续工作流。

适合搭哪些模块

一个实用的个人 AI 基础设施，通常至少包括：

知识入口：网页、PDF、笔记、邮件、聊天记录；
记忆层：长期偏好、项目背景、常用规则；
Agent 层：写作、研究、编程、整理、自动化；
工具层：搜索、文件处理、浏览器、终端、API；
输出层：文章、报告、代码、任务清单、复盘；
安全层：密钥管理、权限隔离、日志和备份。

这个项目更像一个思路集合：提醒你不要只追一个新模型，而要把 AI 嵌进自己的工作系统里。

适合谁看

它适合：

重度 AI 用户；
做研究、写作、编程、咨询、运营的人；
想搭个人知识库和 Agent 工作流的人；
喜欢把重复任务自动化的人；
想把 AI 从“聊天工具”升级成“个人操作系统”的人。

如果你只是偶尔问问题，没必要一上来搭全套。先把一个高频流程自动化，比收藏十个框架更有用。

小结

Personal AI Infrastructure 的价值在于，它把 AI 使用从“单次对话”拉到“长期系统”层面。真正的效率提升，往往不来自某个神奇 prompt，而是来自输入、记忆、工具、流程和输出的持续打通。

如果你已经觉得 AI 工具太多、上下文太散、流程难复用，这类项目很值得参考。

参考来源

danielmiessler/Personal_AI_Infrastructure - GitHub

subagent 会多花多少 token？多 agent 成本与使用策略

Sun, 31 May 2026 14:17:42 +0800

使用 subagent 或多 agent 工作流，通常都会增加 token 用量。区别不在于“会不会增加”，而在于增加多少、换来的并行效率和稳定性是否值得。

如果任务很小，直接让主 agent 完成通常更省。只有当任务可以清楚拆分，或者需要独立复查时，subagent 才更容易体现价值。

subagent 不是更便宜的并行线程

很多人第一次看到 subagent，会下意识把它理解成“并行线程”：主 agent 做一部分，subagent 做另一部分，速度变快，所以应该更划算。

实际不是这样。subagent 本质上也是一个独立的模型调用。它需要读任务说明、理解上下文、读取文件、分析问题，再输出结果。也就是说，它不是主 agent 的免费副本，而是额外启动了一条推理链路。

所以使用 subagent 的核心判断不是“能不能并行”，而是“并行带来的时间节省、质量提升，是否值得额外 token 成本”。

为什么会增加 token

一次 subagent 调用通常会额外消耗这些 token：

主 agent 写给 subagent 的任务说明；
传递给 subagent 的上下文；
subagent 自己读取文件和分析问题；
subagent 生成结果或修改说明；
主 agent 回收结果后的复查、整合和验证。

如果多个 agent 读取同一批大文件，重复消耗会更明显。尤其是代码库分析、长文档翻译、批量内容整理这类任务，如果拆分不好，token 会花在重复理解上下文上。

重复读取上下文是最大的 token 浪费

subagent 真正浪费 token 的地方，往往不是“多开了一个 agent”，而是多个 agent 反复读同一批材料。

比如一个任务要处理 6 篇文章，如果 4 个 agent 都先读完整站点结构、完整技能文档、完整文章列表，再各自处理一点点内容，那么并行会很贵。更好的做法是先由主 agent 确定边界，再让每个 subagent 只读自己负责的文章目录。

更省 token 的拆法通常是：

每个 agent 只负责一个明确目录；
给 subagent 的上下文越短越好；
不让多个 agent 重复做同一类探索；
主 agent 最后统一复查，而不是让每个 agent 都做全量复查；
能用脚本统一检查的部分，不交给多个 agent 反复检查。

换句话说，subagent 的成本控制重点是边界，而不是数量。

大概会增加多少

下面是一个粗略估算，实际消耗取决于上下文长度、文件大小、任务复杂度和 agent 数量。

场景	token 增加
单个 subagent 处理一个小任务	约 `1.2x - 2x`
2-4 个 agent 并行处理可拆分任务	约 `2x - 5x`
多个 agent 各自读取大量文件、做长分析	可能 `5x+`
主 agent 和 subagent 重复读同一批大文件	浪费最明显

这不是精确计费公式，只是经验范围。真正的消耗还要看每个 agent 是否需要读完整文件、是否需要长推理、是否会反复等待和补充上下文。

如何给 subagent 写更省 token 的任务说明

任务说明越宽泛，subagent 越容易自己去探索上下文，token 消耗也越高。更省的写法是把边界写清楚。

一个好的 subagent 任务说明应该包含：

只允许处理哪些文件或目录；
哪些文件只能读，哪些文件可以写；
已有文件是否允许覆盖；
需要保留哪些字段，比如 date、slug、aliases；
输出时只汇报什么结果；
不需要做哪些事情，比如不要跑完整构建、不要改无关文件。

例如，处理翻译时，不要只写“把文章翻译成多语言”。更省 token 的写法是：“只处理 content/post/2026/05/240，读取 index.zh-cn.md，只创建缺失的 index.en.md、index.zh-tw.md、index.ja.md、index.es.md，已存在则跳过，保留 date 和 slug。”

这种说明更长一点，但能减少 subagent 自行猜测和重复探索，整体通常更省。

按文件/目录拆分，比按语言/步骤拆分更省

如果是批量文章翻译，按“文章目录”拆通常比按“语言”拆更好。

比如要翻译 6 篇文章，每篇都要生成英文、繁体、日文、西语。更推荐让一个 agent 负责一篇文章目录内的所有语言，而不是让一个 agent 负责所有英文、另一个负责所有日文。

原因很简单：一篇文章的 front matter、代码块、链接、表格和语义上下文只需要读一次。如果按语言拆，多个 agent 会重复读取同一篇源文，token 会被放大。

同样的逻辑也适用于代码任务。优先按模块、目录、组件拆分，而不是按“先分析、再实现、再测试”这种步骤拆分。步骤拆分很容易让每个 agent 都重新读一遍上下文。

什么情况下值得用

subagent 的价值主要在两点：并行和独立视角。

适合使用的场景包括：

多篇文章批量翻译；
多个目录可以独立修改；
前端、后端、测试可以明确分工；
一个 agent 写实现，另一个 agent 做风险复查；
高风险修改需要第二视角检查。

这类任务里，token 会增加，但总耗时可能明显下降，而且每个 agent 只盯一块内容，注意力更集中。

什么时候值得用一个 agent 做复查

复查型 agent 不一定总值得用。它适合风险高、影响面大、主 agent 容易遗漏细节的任务。

比较值得加复查 agent 的情况包括：

修改涉及登录、支付、权限、数据删除；
多语言内容会影响分类、URL、站内链接；
大范围重构后需要独立找回归风险；
用户明确要求 code review 或风险审查；
主 agent 已经做了实现，但需要第二视角看边界条件。

不值得加复查 agent 的情况也很明确：单文件小改、标题微调、简单 front matter 修正、只跑一个命令。这些任务主 agent 自查就够了。

什么情况下不值得用

不适合使用 subagent 的场景很常见：

单文件小改；
简单问答；
只需要跑一个命令；
改动范围很小；
任务不能清楚拆分；
subagent 必须反复等待主 agent 提供上下文。

这类任务用 subagent 往往只是增加开销。主 agent 直接处理更快，也更省 token。

我的默认策略：省 token 优先，风险任务才加复查

如果目标是尽量节省 token，可以采用下面这套策略：

小任务：不用 subagent。
中等任务：不用 subagent。
大批量任务：默认也不用 subagent，除非用户明确要并行提速。
高风险任务：可以多用一个 agent 做复查，用 token 换稳定性。

这套策略更偏保守。它牺牲了一部分并行速度，但能减少重复读取上下文和重复推理带来的 token 消耗。

如果任务很大但不高风险，我也会优先考虑脚本、批量检查和本地结构化处理。只有当拆分非常清楚，或者用户明确希望并行提速时，才更适合引入多个 agent。

更均衡的策略

如果既想控制成本，又不想完全放弃并行，可以采用折中方案：

默认主 agent 直接做；
只有任务能按文件或目录明确拆分时才考虑 subagent；
subagent 只读取自己负责的文件；
不让多个 agent 同时读同一批大文件；
主 agent 最后统一复查关键字段、测试结果和 Git diff；
高风险任务才增加一个独立复查 agent。

这能避免“为了并行而并行”。subagent 应该服务于明确的效率或质量目标，而不是成为默认动作。

小结

subagent 和多 agent 一定会增加 token 用量。单个 subagent 可能只是增加一点，多个 agent 并行时则可能成倍增加。

是否值得用，取决于任务本身：如果任务能清楚拆分，或者风险高到需要独立复查，额外 token 可能是值得的；如果只是单文件小改、简单问答或常规检查，直接由主 agent 完成更省。

一句话总结：小任务省 token，大任务看拆分，高风险才用额外 agent 换稳定性。

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

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 更像一个了解项目历史的助手。

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 里的 ~/.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，然后开新会话

使用 Agent Skills 取代 VS Code 中 Copilot 的“生成提交消息”的功能

Mon, 06 Apr 2026 13:09:49 +0800

VS Code 的 GitHub Copilot “生成提交消息” 是一个非常实用的功能。配额用尽以后重置周期会非常长。本文是使用本地 Agent Skills，取代这个功能的一个尝试。

问题与目标

本文目标是提供一套可直接落地的替代方案：使用 git-commit-push-zh skill agents 完成标准化提交与推送。

替代方案：`git-commit-push-zh`

该 skill 将“当前改动”收敛为固定流程：

查看变更状态。
确认当前分支。
暂存改动。
生成中文提交信息。
执行 commit。
推送到远端分支。

对应命令如下：

git status --short
git branch --show-current
git add -A
git commit -m "<中文提交信息>"
git push origin <当前分支>

提交信息建议规范

建议统一格式：

`1`	`<类型>(<范围>): <中文摘要>`

类型示例：

feat：新增功能
fix：修复问题
docs：文档更新
refactor：代码重构
chore：维护性改动

示例：

feat(site): 新增全站 head 广告脚本注入
fix(i18n): 修正 relref 相关文章链接路径
chore(content): 合并 AI 工作流分类到 AI工具

常见失败场景

nothing to commit：当前无可提交改动，停止推送即可。
push 失败：优先检查权限、远端分支状态、冲突。
SSH/权限异常：确认凭据与权限后再重试。

附录：原始 `SKILL.md`

以下内容为 git-commit-push-zh 的原始文档，原样保留，便于后续复用与维护。

---
name: git-commit-push-zh
description: 在当前 Git 仓库中将“当前更改”完成一次标准提交流程：检查状态、暂存变更、生成中文提交信息、执行 commit 并 push 到当前分支对应远端。用户提出“提交代码”“提交当前更改”“生成中文提交信息并推送”“git commit push 中文说明”等请求时使用。
---

# 中文提交并推送

使用此技能将当前仓库改动一次性提交并推送到远端。

## 工作流程

1. 查看变更状态：`git status --short`。
2. 确认当前分支：`git branch --show-current`。
3. 暂存当前变更：`git add -A`。
4. 生成中文提交信息（简洁、可检索）。
5. 执行提交：`git commit -m "<中文提交信息>"`。
6. 执行推送：`git push origin <当前分支>`。

## 提交信息规范（中文）

1. 建议格式：`<类型>(<范围>): <中文摘要>`。
2. 类型示例：`feat`、`fix`、`chore`、`docs`、`refactor`。
3. 摘要要求：准确描述本次改动，不写空话。
4. 若仅少量变更，也保持可读性与可检索性。

示例：

- `feat(site): 新增全站 head 广告脚本注入`
- `fix(i18n): 修正 relref 相关文章链接路径`
- `chore(content): 合并 AI 工作流分类到 AI工具`

## 错误处理

1. 若无可提交变更（nothing to commit），明确告知并停止 push。
2. 若 push 失败，先回报关键错误（权限、远端不存在、冲突等）。
3. 常见 SSH/权限问题可在用户确认后重试高权限环境。

## 输出约定

1. 汇报提交哈希、分支名、提交信息。
2. 汇报 push 结果（成功或失败原因）。
3. 仅在确有失败时提供下一步最小操作建议。

工作流 on KnightLi的博客

Personal AI Infrastructure：个人 AI 基础设施应该怎么搭

为什么需要个人 AI 基础设施

适合搭哪些模块

适合谁看

小结

参考来源

subagent 会多花多少 token？多 agent 成本与使用策略

subagent 不是更便宜的并行线程

为什么会增加 token

重复读取上下文是最大的 token 浪费

大概会增加多少

如何给 subagent 写更省 token 的任务说明

按文件/目录拆分，比按语言/步骤拆分更省

什么情况下值得用

什么时候值得用一个 agent 做复查

什么情况下不值得用

我的默认策略：省 token 优先，风险任务才加复查

更均衡的策略

小结

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

domain skills 是什么

它不是让 Agent 盲目点击

它记录的是站点级知识

例子：Amazon 商品搜索

例子：LinkedIn 邀请管理

例子：Shopify Admin

例子：Browser Use Cloud

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

团队可以怎么用

需要注意的边界

简单结论

Claude-Mem：给 Claude Code 加上跨会话长期记忆

它解决什么问题

工作方式

适合什么场景

安装和启动

mem-search 怎么用

和普通项目文档有什么区别

使用时要注意什么

为什么这类工具值得关注

适合谁尝试

参考

最后一句

Codex 开始控制电脑，对以后意味着什么？

这个功能是什么

为什么这件事重要

它能改变哪些工作流

1. 跨软件搬运

2. 多个 AI 工具协同

3. 办公软件自动化

对普通用户意味着什么

对软件形态的影响

现在还不能过度乐观

最后一句

Codex 里的 ~/.codex/skills 和 项目/.codex/skills 有什么区别

两者的区别

~/.codex/skills

项目/.codex/skills

什么时候放全局，什么时候放项目里

当前这个仓库是什么情况

为什么磁盘里有，当前会话里却不一定显示

怎样让 skill 被当前会话暴露

1. 目录放对

2. SKILL.md 头部可识别

3. 新建或修改后，开新会话

4. 项目 skill 最好提前放好

最后一句

使用 Agent Skills 取代 VS Code 中 Copilot 的“生成提交消息”的功能

问题与目标

替代方案：git-commit-push-zh

提交信息建议规范

常见失败场景

附录：原始 SKILL.md

`mem-search` 怎么用

Codex 里的 ~/.codex/skills 和项目/.codex/skills 有什么区别

`~/.codex/skills`

`项目/.codex/skills`

2. `SKILL.md` 头部可识别

替代方案：`git-commit-push-zh`

附录：原始 `SKILL.md`