我这周最想讲的一件事，是同一个任务同时交给多个 Agent、多个模型去做。做法不复杂，但比单一 Agent 的效果好很多。
现场我演示了一遍。Chrome 里分别打开 ChatGPT、Grok 和 Gemini 的网页端，然后跟 Agent 说：我在 Chrome 里分别打开了这三个网页端，请你同时帮我调查一下 Z Code 上传争议，最后汇总一份报告。它会自己去开浏览器、发问、收结果。
让 Agent 调动网页端 AI，等于多了一支检索队
你可能会问，Agent 凭什么能操纵 Chrome？办法挺多。用 OpenAI 的 Codex，可以在 Chrome 里装一个 Codex 插件；用 Claude Code，也有对应的插件；用第三方 Agent，比如 Pi Agent，可以装一个 Chrome DevTools 的 MCP，也就是大家说的 CDP。那次演示我用的是 Codex CLI 驱动浏览器。
为什么要绕这一道，不直接让 Agent 自己联网查？我的体感是，Agent 自带的联网检索不如网页端，网页端在联网检索上做了很多优化，信息整合也更成熟。更现实的一点是免费额度：ChatGPT、Gemini、Grok 不订阅也有额度，只是给你用轻量级模型，但轻量级模型也一样不花钱。等于你手里多了一支免费的联网检索队。
有人当场问，这么干是不是很费流量。其实不会。它做的事很简单：把同一份上下文分别发给三个网页端，让它们各自执行，再把结果收回来。网页端对你来说就是一项类似 MCP 的服务，只不过你不需要真的去装一个 MCP。
平时我把任务交给它去网页端跑，还会看到一些细节。它会自己不停追问——觉得 ChatGPT 答得不够好、或者问题没答完，它就继续追下去。这比人自己坐在那里敲字快得多。那次演示里它一开始打开了 Claude，我提醒它：不需要 Claude，打开 Grok 网页端，把任务也发给 Grok。
等三家结果回来，那次的对比很清楚。ChatGPT 最准确，边界最完整。Grok 信息丰富，但混入了二手文章里没核验的数字。Gemini 明显漏检，也没有主动尝试纠错，结论是错的。这个判断只针对那一次查询；不过结合我平时的体感，我对 Gemini 的评价一直不高——不光是它的 Agent 拉垮，网页端也一样。
为什么一个模型不够用
同一件事交给三个模型，不是为了凑数，是因为模型的性格差别很大。
我现在主力用三个。第一个是 GPT-6 Astra，严谨，甚至严谨到烦人。你对它考虑不周或者不合规的地方，它会反反复复跟你确认；你急着让它干活的时候，会觉得它拖。第二个是 DeepSeek V4.1 Flash，另一个极端：干活快，你说一件事，它马上做完，你说了第一步，它恨不得把第四步第五步第六步一起干了。问题是偶尔会出纰漏。第三个是 GLM 5.3 Flash，我体感它介于两者之间，比 DeepSeek 保守一些，执行任务也还可以，正好用来查漏补缺。
所以最顺手的组合是：GPT 当主控，同时让 DeepSeek 和 GLM 并行跑，最后让 GPT 来汇总。快和稳同时拿到，也不容易留纰漏。
如果任务很大很长，一次指令根本做不完，我会再加一层：GPT 负责规划，GLM 和 DeepSeek 负责执行；执行完 GPT 审核，不满意就打回去重做。说白了，GPT 当领导，DeepSeek 和 GLM 当两个干活的员工。
写代码的任务还能更野一点。把两个任务分别开两个 work tree，让它们各自实现一遍，然后 battle 一下，最后我自己当仲裁，看哪个做得好就用哪个。
这套分工背后是我一个很朴素的判断：你不会指望一个员工面面俱到。团队里要有逻辑缜密的老工程师，也要有干活快但毛糙、积极性很高的年轻人，还要有人帮你查漏补缺。模型的能力边界不一样，不该盯着一个模型往死里薅，把它们组合起来用才顺手。
编排层：Paseo，和我的九个员工
要让不同的 Agent、不同的模型协作，你需要一个多 Agent 的编排工具，也就是调度层。
这里有个容易踩的坑：把 Agent 和模型锁死。DSH 是专门为 DeepSeek 优化的，Codex 专门为 GPT 优化，Claude Code 专门为 Claude 优化，它们都属于锁定型。我自己的体会是，锁定型 Agent 通常只在一类任务上跑得好，换个任务就不行了。模型做强化学习有点像人：天天打篮球的人，你让他去打乒乓球，就会笨手笨脚。所以我不建议用一种锁定组合去覆盖所有任务。
我推荐的编排工具是 Paseo，开源、轻量，能把不同的 Agent 和模型组合起来。Codex 只能编排 GPT 系的几个模型，Claude Code 也只能编排 Sonnet、Opus 那几个，但只要你把模型和 Agent 配进 Paseo，它就能拿不同的 Agent 配不同的模型去执行任务。
现场我做了个演示：让搬砖工和高材生分别独立调查 Z Code 上传争议，最后汇总。搬砖工是 Pi Agent 配 GPT-6 Astra、thinking 设 Low；高材生是 DSH 配 DeepSeek V4.1 Flash。主控 Agent 接到命令后自己去启动子 Agent，左下角能看到两个任务同时在跑，它还额外做了第三路核验，相当于三个 Agent 一起干活。执行过程中你可以直接跟子 Agent 对话，也可以不管它，只看父进程。
我给自己配了九个角色，每个都写了一段描述，Paseo 会根据任务自动挑最合适的那个派出去：
- 搬砖工：Pi Agent 配 GPT-6 Astra，thinking 设 Low。
- 苦力工：用更轻的 GPT-5.6 Sol，干一些简单的活。
- 高材生：DSH 配 DeepSeek V4.1 Flash，跑得又快又糙。
- 笔杆子：Pi Agent 配 DeepSeek，专门写文章。同一个 DeepSeek 模型，配 DSH 写出来的文章 AI 味很重，换成 Pi Agent 之后好很多，因为 Pi Agent 不对模型能力做额外限制。
- 小媳妇儿：GLM 5.3，最后兜底的那个。这名字我觉得不太合适，回头会改。
- 再加上班主任、老法师、程序员、架构师，一共九个。
程序员和架构师我用 Codex，因为 Codex 在代码管控上的权限设置更严格，写代码更严谨。你不需要每次都手工指定派谁，描述写清楚之后，它会自己判断。这就不像跟一个 Agent 对话了，更像指挥一个 AI 团队：绝大多数时候，你只需要把指令下给指挥中枢，由它调度下面的人。
有人问这些子 Agent 之间数据文件共不共享。共享，因为数据和上下文的管理权在主 Agent 手里，主 Agent 调度子 Agent，权限都在你自己手里，文件也都在你本地。我通常的做法是：为了不把大量上下文直接传过去，会把指令和资料写到一个临时文件里，让子 Agent 自己去读，这样能省很多 context。
顺便说一句云端 bot。像 Grokbot 这类跑在云端的方案，思路有点类似，但有两个限制：第一它跑在云端，第二你没办法给它配置不同的 Agent 使用不同的模型。所以它没有本地这套灵活。
Harness 越简单，模型越能发挥
配好团队之后，一个反直觉的结论在我这儿冒了出来：Agent 越简单，任务反而跑得越好。
现在的模型能力越来越强，而 Agent 给模型加的那一层 harness，本质是一堆约束和限制。模型弱的时候，它能拖住下限；模型强了以后，它会往下压模型的表现。OpenCode 在我眼里就太臃肿了，我已经几乎不用。
所以我的选择是充分发挥模型的原生能力。现在我百分之七十到八十的场景都用 Pi Agent，只有编程场景会用 Codex，再辅助用一点 DSH。
分工是有理由的。Codex 对权限和沙箱管得很死，这适合 code review、后端代码和架构设计，但它写数据调研报告、做文字创作、做前端设计都很差。所以我把 Codex 严格限定在编程场景，尤其不拿它写前端。DSH 相对新，据 DeepSeek 自己的员工介绍，它对 DeepSeek 的缓存做了更好的优化，所以重度使用 DeepSeek 编程的话可以配一个。日常其余场景，我用 Pi Agent。
那不给模型加约束，它会不会跑偏？有可能。我防跑偏靠的不是 harness，是两件事。第一，并行跑两个互补的模型，要么最后合并答案，要么让一个监督另一个。模型之间相互监督，比 Agent 的 harness 去监督强得多。第二，对已经形成固定流程的任务，用自己写的 skill 去约束——限定数据源、执行步骤和判断标准，这比 harness 有效。
这两件事做完，我自己跑下来是这么一个结果：多模型交叉检查加上自己写的 skill 之后，用什么 Agent 都差不多，越简单的 Agent 效果越好，越复杂的反而越差。这也是我为什么说，你不需要每天追 Codex 又升级了什么、模型又加了什么新功能。你有一套自己的工具和模型组合，效果远远超过天天追最新工具。
一次配置，三个 Agent 共用
三个 Agent 并行用，最怕的是各配各的，配置和规则慢慢就分叉了。
我的做法很简单：它们统一遵循一个 AGENTS.md 文件。我在用户根目录下放一份 AGENTS.md，然后在三个 Agent 各自的目录里做符号链接。skill 也一样，全部放在公共目录 ~/.agents/skills，这三个 Agent 默认都去读它。本地常用的工具，我也配置成 skill。所以三个 Agent 读同一份全局配置、同一份 skill，通用能力基本同步。
当然不可能百分之百同步。比如 Codex CLI 会有一些 OpenAI 官方提供的插件，Pi 和 DSH 没有。但通用部分是统一的。
skill 还要分作用范围。我知识库里现在有十九个 skill，它们放在知识库目录下，不放进全局。全局 skill 只放两类：Paseo 的多 Agent 编排，以及这台工作站上所有本机工具的调用方式，比如视频剪辑、音频转录。代码有代码的 skill，知识库有知识库的 skill，各管一摊。
Skill 砍到 19 个，扩展只留必要的
这次我认真清了一遍工具，结论是：能不装就不装。
Skill 我从三十多个砍到十九个，因为模型变强以后，很多 skill 已经没必要了。有人到处找 skill，甚至还有一个叫 Find Skill 的 skill，专门帮你找 skill 再自动装上——我的建议是都不需要。skill 是作者按自己的场景写的，你可能只用得上它百分之十的功能，剩下百分之九十是硬塞给你的。skill 写得好确实不太占上下文，但 skill 一多就是负担，因为你根本不知道它什么时候会被触发。
到今天为止，第三方 skill 我只装了 Paseo 的那六七个，它们就是多 Agent 编排能力。装到全局目录之后，只要 Paseo 进程开着，Pi Agent 也好、DSH 也好，都能直接调用它的编排能力。Paseo 不是强绑定的软件：你可以不用它的桌面端，不用它的 CLI，不用它的内嵌浏览器，只借用它的多 Agent 编排，也完全可以。
Codex 上我没装任何插件，DSH 上也没有。Pi Agent 上我只装了两个扩展：一个是 Pi Web Access，配上搜索 Key 之后它就有了联网检索能力，这个我觉得必要；另一个是用于调用 MCP 的扩展。而 MCP 我只用一个，就是控制 Chrome 浏览器的 CDP。
这里顺便提一句，Pi 的 MCP 是动态加载的。我了解到 Claude Code 不是这样，你在它里面注册五个 MCP，一启动五个全加载，context 占用很恐怖；Pi Agent 不会，你注入了 MCP，context 也不增加，等第一次用到的时候才加载。对上下文很省。
所以整套东西收下来就是：Paseo 的几个 skill、Pi Agent 的两个扩展、一个 MCP，结束。我的精力放在选择少而精的组合、把技巧练熟，而不是满世界找扩展、找技能、找 MCP。我最后推荐给大家的也就两个，都是开源的：Pi Agent 和 Paseo。
Agent 怎么连浏览器，以及一条隔离原则
浏览器这块，我三种方案都在用。
用 Codex，直接装插件让它操纵 Chrome。用 Pi 或 DSH，如果你在 Paseo 里，就不需要装任何插件，Paseo 内置了浏览器，会动态注入 MCP，你直接跟它说“用 Chrome 打开某个页面”就行；第一次打开是未登录状态，你在它单独开的标签页里登录一次，它就会记住。如果你不想用 Paseo，想留在自己的终端里，那就配一个 CDP 的 MCP，然后在本地单独起一个 Chrome，开着 9222 调试端口，通用，什么 Agent 都能通过它操纵浏览器。
但这三种方案里有一个风险要讲清楚：如果你让它直接操纵你平时用的 Chrome，那你的敏感账号也在里面，Agent 真的有能力打开页面、修改内容。所以最好把 Agent 用的浏览器和你自己用的浏览器隔离开。
隔离也有两个办法。一是用 Paseo 内嵌的 Chrome，它的配置文件是完全隔离的；二是配 CDP 的 MCP，本地起一个独立 profile 的 Chrome。我因为主要只在编程场景用 Codex，所以还好，但这条原则我觉得值得每个人遵守。
我自己的几条选择
顺着上面这些，我自己有几条固定的做法。
第一，装在自己电脑上的 Agent，我尽量挑开源的。现在主要用三个：Pi Agent、Codex CLI 和 DSH。Codex 要分清楚，CLI 是开源的，桌面端不开源，但两者配置共享、功能一样，插件、Browser Use、Computer Use 都齐，所以我安全起见用 CLI。MiniMax 的 Agent、OpenCode 也都是开源的，我没那么多时间都试，但从方向上，闭源的本地 Agent 我不再考虑。
第二，敏感信息不交给云端模型。金融账户、交易记录这类信息，我宁愿麻烦一点，用本地的模型去处理。我本地跑的是 2.4 比特量化的 DeepSeek V4 Flash，对我来说足够好。
第三，能跑本地就跑本地。云端的 bot 我尽量少用，家里有一台 Mac Studio M4 工作站常年开着，这些环境都跑在上面。
第四，很多高确定性的任务没必要用 AI 模型。很多高确定性的流程根本没必要用 bot，用 bot 反而浪费 token，模型稍微抖动一下，执行结果就不一定精确。我自己有个发推文的定时任务：推文写好后先放进本机队列，每天四个时间点取出来发，因为几条推文集中在同一时段发出去，平台可能只给中间两三条流量。它怎么发的？我的 Chrome 开着 CDP 端口，程序连上去，打开我的 X 账号、打开发帖页、打开输入框、填入内容、点提交，就完了。这种活根本不需要模型。
最后说回工具这件事。不要被厂商绑定，也不要被模型绑定，组合出一套自己的工具箱——工具在精不在多。
