个人学习记录 · STAGE 05
这一阶段要解决的问题 学习怎样拆分搜索、整理、审阅任务，并检查不同 Agent 交回的证据。
子 Agent 的价值来自分工和复核。这里从不同 Agent 的体验出发，再进入多 Agent 搜索、资料对比和具体研究场景。
本页收录 7 篇原文。正文来自个人 Google Drive 原文库，已移除 x.com 地址和 t.co 媒体短链。原文涉及的版本与产品状态以发布日期为准。
2026-08-19 21:39:36 · 小墨同学原文
我想分享的是，一定要多尝试不同的Agent，真的你会回来感谢我的！
因为每个Agent时间都有相似之处，但是又有很多不同之处。
比如我自己最常用的，Claude Code、Codex 他们两个之间我觉得差别最大的就是生态上的差距，没有几个人可以完整的体验Claude的产品线，但是Codex可以。
Pi Agent和Deepseek harness 两个从里层就有很大的区别，一个是简洁的设计AI不需要这么多，一个万物皆插件的设计思维。
还有就是我自己常用的Hermes和Openclaw，两个产品类似，但是大方向不一样，一个是讲究自进化低维护skill优先，一个是插件生态和独特的记忆体系，各有优点。
用了这么多，但是有部分核心设计都是共通的，用多了，你才能知道哪一些才是你真正需要的想用的
2026-08-24 18:52:20 · 小墨同学原文
Pi Agent 的 Sub-agent功能一定要用起来！
虽然官方没有内置相关的功能，但是只需要安装插件就能用上。
再多任务并行的情况下，是帮你提效的好帮手，尤其是处理一下简单重复数据量大的时候，就非常合适。
这里我简单介绍一下工作原理：
- 主 Agent 负责拆任务
你平时对话的 Pi 就是主 Agent。
比如分析一个大型项目，它可以让 scout 找入口文件，让 researcher 查文档，再让 reviewer 检查风险。
你只需要把目标和限制讲清楚，剩下的任务分配交给插件。
- 每个 Sub-agent 都有独立 context
大部分插件会单独启动一个 Pi 进程，让 Sub-agent 自己读文件、调用工具。
它干完以后，只把结论交回主 Agent，不会把几十次工具调用全部塞进主对话。
好处是省 context，缺点是它不一定知道你之前聊过什么。所以任务里最好写清楚路径、目标和需要返回的结果。
- 不同 Agent 可以使用不同模型和权限
查代码的 scout，只开放 read、grep、find。
负责 Review 的 Agent 可以看代码、跑测试，但不一定需要修改文件。
真正干活的 worker，再开放 edit、write 和 bash。
简单任务还可以交给便宜模型，复杂判断再用强模型，不需要所有 Agent 都用最贵的配置。
- 支持单独、并行和链式执行
官方 Sub-agent 示例支持三种常见方式：
Single：一个 Agent 完成一个任务 Parallel：几个 Agent 同时处理不同任务 Chain：scout 找代码 → planner 出方案 → worker 修改 → reviewer 检查
自由组合任务，不仅可以让任务分开跑，而且可以组合在一起跑最终的结果会聚到一起是分开处理
但是相关缺点也是有的，就是对Token的消耗会乘几倍增长，如果你的工作不是很紧急，或者是对应套餐额度不够也不建议长期使用
如果大家对这部分感兴趣，下次我就介绍一下相关的插件，把你的Pi 打造成一个多线程并行开发工作台
2026-08-28 10:16:28 · 小墨同学原文
Pi Agent 的 Sub-agent 我一直在用，最近我又拿 Apodex 1.1 跑了一轮多 Agent 搜索。
它处理资料对比的方式，和普通 Deep Research 不太一样。
Pi Agent 本身没有内置 Sub-agent，需要通过插件扩展。你可以让 scout 搜资料，researcher 整理信息，再交给 reviewer 检查。每个角色使用什么模型、开放哪些工具和权限，都能自己配置。
这种方式很灵活，适合喜欢自己搭 Agent 工作流的人。
这次我给 Apodex 1.1 的任务，是核对 Pi Agent、Codex CLI、Claude Code 和 FrontierAgent 的多 Agent 能力。
这些工具更新都很快。同一项功能可能在旧文档里没有，最新版本已经加入，也可能只是插件支持，最后却被写成官方内置。
所以我从一开始就限制了资料范围，只接受官方文档、GitHub 仓库和版本更新记录。
Apodex 会根据问题拆分搜索路线。多个 Agent 分头查不同工具，阶段结果持续汇总到同一个任务中，最后再集中比较。
我这次想看的，是它能不能把一个资料多、版本杂的任务持续做完，并把每条结论的来源留下来。
最终表格会单独区分官方内置和插件实现。不同官方页面出现冲突时，它会列出各自的来源和更新时间。官方没有明确说明的地方直接标成未知，不会为了填满表格补一个答案。
交付结果还会经过 Statement Review。关键结论与生成过程分开检查，遇到证据不足、引用不匹配或资料冲突时，会留下对应的检查记录。
两种多 Agent 的使用方向也很清楚。
Pi Agent 适合自己组建团队。角色、模型和权限都能深度调整。
Apodex 更适合多路搜索，把分散的资料放到一起比较，再交付一份可以继续核查的结果。
如果你经常需要确认某项能力究竟是官方支持、插件提供，还是目前没有明确资料，这种工作方式会比较实用。
FrontierAgent 是开源的单机 Agent harness，支持 ReAct 和 Agent Team。macOS、Linux 可以一条命令运行，无需强制预装 Docker。觉得有用可以去 GitHub 点个 Star。
Apodex 1.1 mini 是开放权重的 35B 模型，可以本地部署，也能搭配 FrontierAgent 使用。
Apodex 1.1 在线工作台已经上线。注册新用户有 credits，可以上传自己的文档、数据或表格跑一次。API 平台目前免费两周。
原帖包含图片或视频，媒体素材待后续整理。
2026-08-28 11:24:12 · 小墨同学原文
我用Pi 接入 Apodex 1.1，让它帮我查查孙宇晨说的是真是假🔥
孙宇晨那篇《我的女友景甜》发出来以后，相关话题很快冲上热搜。
文章写了大量恋爱和财产纠纷细节，开头与结尾又标注了纯属虚构。随后代理律师公开谈到三千余万元财产争议，景甜一方也作出了回应。
几种来源混在一起以后，很多内容已经分不清是公开事实、单方说法，还是自媒体根据原文继续加工出来的故事。
我刚好把 Apodex 1.1 接进 Pi Agent，就拿这条新闻跑了一轮。
我让模型自己搜索孙宇晨的原文、双方回应和律师公开说明，继续追查媒体报道的最初出处。遇到互相冲突的说法要保留，原始页面打不开也要明确标注，证据不足的内容不能写成事实。
Pi Agent 提供搜索和网页读取工具，Apodex 1.1 决定从哪里开始查，哪些内容需要交叉验证，最后把新闻整理成一份带来源的时间线和事实核查表。
这里测试的就是Apodex模型的真实搜索能力和信息整合能力，大家也知道在Pi运行模型可以比较真实的反馈出模型的真正实力。
到底是李逵还是李鬼测试一下就知道了。
现在Apodex API 平台目前限免两周，感兴趣的可以自己去体验一下，链接我放评论区了
原帖包含图片或视频，媒体素材待后续整理。
2026-08-28 14:21:48 · 小墨同学原文
看到这个用 Apodex 搜《红楼梦》的例子，我想到 Pi 的 Sub-agent 很适合处理这类问题。
《红楼梦》里的很多问题都牵涉不同版本、脂批和后来的研究观点。模型如果顺着最先搜到的解释写下去，很容易把原文、校注和后人推论混在一起。
接进 Pi 以后，可以让 Sub-agent 分头查。一个只找原文和版本出处，另一个整理不同研究观点。主 Agent 再检查引用来自哪里，把暂时无法解决的冲突保留下来。
这里很考验 Apodex 1.1 怎么拆问题，也能看出它会不会检查 Sub-agent 带回来的材料。
搜索数量决定能找到多少资料，来源判断决定最后的回答能不能信。
这种没有唯一标准答案的问题，很适合拿来测试 Pi Sub-agent 和 Apodex 1.1 的组合。
原帖包含图片或视频，媒体素材待后续整理。
2026-08-30 20:01:38 · 小墨同学原文
我开始让 Pi 学我怎么分析自己的 X 推文了🔥
以前我复盘X推文数据，基本都是自己来，其实很浪费时间。
要去看曝光、点赞、收藏，再回头看开头有没有吸引力，中间哪一段信息密度最高，为什么有的内容明明写得不错，但就是没人看。
做多了以后我发现，其实我每次分析的思路都差不多。
那就没必要每次重新告诉 AI 一遍。
我现在开始把这套流程直接固化进 Pi。
比如以后我把自己的推文丢给它，它会按照固定顺序去看：
1、先判断这篇内容真正吸引人的点是什么，而不是只看数据高低。
2、再拆开头、结构、选题和表达，找出哪些地方值得继续保留。
3、最后结合我以前表现好的内容，告诉我这个方向还能往哪里继续挖。
现在我用Pi 不再是单纯的去封装成skill，而是却发现生活中的习惯把它固化下来，用Pi的自定义插件替我解决。
这也是我现在越来越喜欢 Pi 的地方。
原帖包含图片或视频，媒体素材待后续整理。
2026-09-03 08:21:25 · 小墨同学原文
OMP 越做越狠了：一个 Agent，开始配一整个模型团队。
以前使用Pi 开启子线程代理，我都会纠结一个问题：
是不是所有的Subagent都需要继承主线程的模型等级，但是实际使用下来消耗又高，使用又慢。
但是我在 Oh My Pi 这种多 Agent Harness，找到了一个模糊的方向。
主线程Agent、Advisor、Subagent 需要分工明确什么人干什么活，如果全部塞同一个最强模型，成本高不说和速度还慢。
现在 OMP 社区已经开始讨论，把不同角色的模型彻底拆开：
1、Main Agent 要的是综合能力
负责理解需求、做决策、控制整个任务，所以更适合放能力最强的模型。
2、Advisor 要的是判断能力
它不一定负责真正干活，更多是盯着主 Agent 有没有走偏，所以推理和判断比速度更重要。
3、Subagent 更看性价比
查资料、扫代码、跑简单任务，这些东西如果一下开十几个，全用顶级模型完全没必要。
我自己其实已经是类似的用法。
主 Agent 我会用 GPT-5.6 Sol，Advisor 放 GPT-5.6 Terra，真正大量跑 Subagent 的时候，反而会优先用 DeepSeek、GPT-5 Mini，甚至一些免费的模型。
强模型负责做判断，便宜模型负责干杂活，做执行层。
这个方向可能就是我正在寻找的破局之道，动态分配任务和模型，虽然复杂，但是又便宜又高效。
原帖包含图片或视频，媒体素材待后续整理。
完成这一阶段后，继续阅读第 6 阶段 把 Pi 变成长期工作流。
