我的 AI 工作台：多 Agent 协作和统一上下文

写在前面

我目前从事数据平台和 AI 相关的技术售前工作。过去一年，AI 在我的工作和生活中逐渐从一个简单的问答工具，变成了在生活和工作中真正能帮到我的工具。现在工作上的技术调研、方案梳理、代码脚本、部署排障和演示材料，生活里的日历、待办、财务和家庭网络管理，基本都有 AI 参与。

这篇文章想分享一下我目前使用 AI 的方式，以及这一年摸索下来的一些经验和教训。没有太多高深的东西，主要是自己真实的使用经历，希望能给大家一些参考，也希望大家给出一些建议。

订阅和硬件

工具或服务	套餐与来源
ChatGPT / Codex	Pro ，$200/月，iCloud 订阅，这个月底应该会降到 $100
Claude Code	Pro （$20/月）×2 ，iCloud 订阅，使用 cswap 切换。Max 要加钱，感觉性价比不高，也没有 Fable 使用需求，所以没升，犹豫中
Cursor	公司企业订阅，Composer 畅用，每月 $300 额外的额度，我都用来跑 Opus 5.5
X Premium	Premium ，$30/月，刚开始订阅，主要用 Grok Bot
ZenMux	个人 Starter 订阅，$20/月

硬件

目前我的主力是一台放在家里的旧笔记本，安装了 Linux Mint ，平时基本不用管它，就让它一直开着。基本上所有的 AI 任务都跑在上面，通过 Paseo 调度，通过 RustDesk 远程访问。

我在家主要用 Windows 台式机，通过 Paseo 连接到这台 Linux 。

另外有一台 MacBook Air ，上面跑 Codex Desktop ，主要用它的电脑操作能力：Codex 能直接看屏幕、移动鼠标、敲键盘，像人一样去操作 Mac 上的浏览器和各种应用。录 Demo 视频时，要在真实的产品界面里点击、展开、滚动，这类需要操作图形界面的活，交给 Mac 上的 Codex 最方便；家里那台 Linux 则主要跑命令行和后台任务。出门在外，我也会用这台 Mac 通过 Paseo 连回家里的 Linux 。

多 Agent 协作：用 Paseo 组一个团队

前面讲过，我主要通过 Paseo 远程连接 Linux ，在那里拉起和调度各个 Agent 。Paseo 支持子 Agent 配置和多个 Agent 协调，所以我可以只跟一个总控 Agent 说话，由它再去派活。

角色分工

目前我把 Agent 分成了六个角色，也是模仿现在比较流行的用 Agent 组建软件团队的做法。每个角色都是独立的会话，即使模型相同（比如 Lead 和 Architect 都是 Opus ），也会单独开一个子 Agent 。

角色	使用模型	主要职责
Lead （总控）	Opus 5.5 · Medium	理解需求、拆分任务、分配工作、协调其他 Agent ，最后负责验收
Architect （架构师）	Opus 5.5 · High	设计技术方案、确定整体架构，解决复杂的技术问题
Developer （开发）	Composer 2.5 · Fast	编写代码、修复 Bug 、编写脚本和文档，基本无限用
Reviewer （审查）	GPT-6 Astra · High	独立审查方案和代码，检查潜在问题，提出改进建议
QA （测试）	GPT-6.1 Sol · XHigh	设计并执行测试，验证功能是否正常，复现问题
DevOps （环境与交付）	Composer 2.5 · Fast	准备运行环境、构建打包、部署和交付，基本无限用

任务怎么流转

一个普通任务大致这样走：我把需求交给 Lead，Lead 定好范围和验收标准后派给 Developer 实现并自测；改动风险高一些的，再交给 Reviewer 审代码、QA 实际跑一遍；有问题退回 Developer 修，最后由 Lead 核对真实的输出结果再交给我。小改动的话，Lead 直接处理掉。

另外两个角色按需加入：

Architect：涉及技术方案时，Lead 先把问题和现有证据交给它，由它出方案、定接口和约束，并写明要怎么验证，再交给 Developer 实现。它不常驻，只在有具体的技术难题、需要做设计取舍，或者实现中发现原方案不成立时才叫它；它只管方案，不派工，一般也不自己写代码。
DevOps：涉及环境准备、构建打包、部署时才安排。它可以和 Developer 同时开工，提前把环境准备好；产物打好包之后，再由 QA 拿同一份产物验证。

接入 pstack

角色定了「谁来干」，但没管「怎么干」。最近我在把 pstack 融进这套流程，它是 Cursor 官方的一套工程方法库，把澄清需求、读代码、TDD 修 Bug 、评估改动影响、性能测试等常见工程活拆成了一个个 Skill 。

不过 pstack 自带一套编排方式，会自己拉子 Agent 、跑多模型，这和 Paseo 的角色分工是冲突的。所以我没有整套照搬，而是让 AI 写了一个很薄的路由 Skill ，用一张表定义「什么情况、通常哪个角色、读哪个方法、要交出什么」。Lead 派工时只在任务开头加一句「先加载路由 Skill 」，每个角色按手头任务自己挑方法用。谁能派工、谁能写代码、什么时候必须停下来，仍然以 Paseo 的编排规则为准。

上下文管理：用 Obsidian 统一记忆和规则

为什么用 Obsidian

用多个 LLM 的问题在于如何跨模型管理上下文。Claude Code 、Codex 、Cursor 各有各的记忆和配置，互不相通，同一件事要讲好几遍。

我的做法是用 Obsidian 来管理和存放所有上下文。说白了就是一堆 Markdown 文本文件，但这正是好处：哪家的 Agent 都能直接读写，不绑定任何一个客户端； Obsidian 还能把它们同步出去，不光是别的电脑，云端的机器也能直接共享这套上下文，不管是自己的 VPS ，还是 Grok Bot 、GPT dot 这类云端服务。客户端自带的记忆我只当临时缓存，长期的东西都以 Obsidian 为准。

目录规划

目录规划如下：

目录	放什么
`preferences/`	给 Agent 的规则：通用规则、编排、Worker 边界、工程、文档
`projects/`	项目上下文，包括「背景、约束、状态、决策、踩坑、下一步」等内容
`knowledge/`	能跨项目复用的结论
`MCP/`、`skills/`	工具定义和操作说明的唯一源头，Claude Code 、Codex 、Pi 等各客户端软链接到 Obsidian 本地目录

规则入口：AGENTS.md

~/.claude/CLAUDE.md、~/.codex/AGENTS.md、~/.cursor/AGENTS.md 都软链到同一个 preferences/AGENTS.md，改一处，所有 Agent 都生效。

这个入口文件采用渐进式披露：本身只写几条通用规则，比如能自己查的日志和配置先查了再回答、同一个方法失败两次就换思路、做完要验证、没验证的要说出来。具体规则拆成几个主题页，入口文件里只放一张「什么场景读哪页」的索引：

场景	阅读
项目任务开始、检索或写记忆	`ai-workflow`
作为 Lead 派工、选角色、验收	`agent-orchestration`
作为 Worker 接受 Lead 的派工	`agent-worker`
代码、配置、排障、脚本	`engineering`
写文档、改文稿、审阅	`documentation`

Agent 按当前任务只读命中的那一页，上下文不会被一大堆用不上的规则占满。多 Agent 的规则分两页：agent-orchestration 给 Lead ，管怎么派工和验收；agent-worker 给 Worker ，管干活的边界和交付。

定期整理

每个月第一个周日凌晨会跑一个定时任务，让 AI 重新整理 Obsidian 里的这些文档，保留有价值的内容，删除重复和过时的信息，结果通过 Hermes 推送给我，我再抽空看一眼。

凭据不进笔记

密码和密钥不进 Obsidian 。我的所有密码都用 1Password 管理，通过 1Password 的开发者环境和单独的 Vault 两种方式把密钥分享给 Agent ，笔记里只写「去哪取」，不写值。

踩过的坑

各家客户端的配置不共用。 MCP 、Skill 、规则文件，每个客户端都要单独部署一份，所以我才坚持「 Obsidian 是唯一源头，其他地方都是软链或副本」。
自带记忆和 Obsidian 会记重复。 有的客户端默认开着自己的记忆，同一件事两边都记，时间久了还会互相矛盾。现在一律以 Obsidian 为准。
多个 Agent 之间背景不同步。 派出去的 Worker 不知道前因后果，容易重复劳动或者跑偏。不过现在用 Lead 来统一管这些事情。

最后

这套东西是一年里一点点攒出来的，欢迎在评论区交流，也欢迎指出我这套里不合理的地方。