十三大项目的源码分析已经覆盖了编程 Agent、通用任务 Agent、宿主型 Agent、群体仿真这四条线。但 Agent 工程的地图远比这大——以下是经过筛选的、值得后续学习的开源项目。每个项目不只告诉你"它是什么"，更告诉你"它和你已经分析过的项目在哪些具体的技术决策上不同、你会从中学到什么、建议从哪里开始读代码"。
筛选原则：不凑数、不列"有名但跟你已有分析重复的"。每个项目必须满足：看了之后能让你对 Agent 工程有新的理解，而不仅是"又多知道了一个 Agent"。
读者设定：已经读完至少 2–3 份本仓库的单项目源码分析。如果你还不熟悉 Agent 主循环的基本概念，先回去读阶段一。
一、最高优先级：和你已有的分析形成最尖锐对照
这三个项目不是"也有名所以该看"——而是"它们的设计哲学跟你分析过的十三家形成了最尖锐的对照，看了之后你对 Agent 工程的理解会提升一个层次"。
1. Aider——编程 Agent 里"少即是多"的极致样本
GitHub：Aider-AI/aider · Python · Apache-2.0
你已有的分析：十三家编程 Agent 里，Claude Code 约 40 个工具、hermes 74 个工具、Codex 126 crate workspace——都是"重型"路线。大量的代码花在工具系统、权限系统、压缩策略、子 Agent 管理上。
Aider 的回答：轻量到极致。核心是一个"地图-编辑"循环——先让模型读取项目文件生成一个"代码地图"（map），然后基于地图决定改哪些文件（edit）。没有复杂的工具分类、没有多层权限裁决、没有子 Agent 池。整个项目的核心代码量比你分析过的任何一个编程 Agent 都小一个数量级。
你会学到什么： - "多少 agent 基础设施是多余的"这个问题的实战答案。Aider 用最少的代码验证了：模型 + 地图式编辑 + 简单的重试，能覆盖多少真实编程场景 - 地图式编辑 vs 工具调用式编辑。你分析过的 Agent 都是"模型调工具→工具读文件→结果回喂→模型再调工具"。Aider 是"模型先画出整张地图→一次性改多个文件"。前者灵活但慢，后者快但需要模型能"一览全局" - 自己维护的 Polyglot 基准。Aider 的 Polyglot 基准（225 题 6 语言）已经成为业界参考。看懂它怎么设计评测题目、怎么筛选难度、怎么控制成本——你就能自己设计评测
建议的阅读入口：
- aider/coders/base_coder.py：核心的 map-edit 循环，理解"和 while-tool-loop 的本质区别"
- benchmark/README.md：Polyglot 基准的设计文档——怎么从 697 道题筛出 225 道、怎么控制成本
- aider/repomap.py：代码地图的生成逻辑——怎么把一个项目的文件结构压缩成模型能理解的"地图"
和你已有分析的对照表：
| 维度 | Aider | 你分析过的代表 | 差异的本质 |
|---|---|---|---|
| 主循环 | map-edit（两阶段） | while-tool-loop（多轮） | "先看全貌再动手" vs "走一步看一步" |
| 工具数量 | 极少（读文件、写文件、跑命令） | 20–74 个 | 模型不需要被"告诉"怎么干活——它自己知道 |
| 代码规模 | 轻量（几万行 Python） | 重（几十万行 Rust/TS） | 少维护负担 vs 多工程精度 |
| 权限模型 | 简单（确认改哪些文件） | 复杂（五关裁决 / constitution / provenance） | "信任模型" vs "验证模型" |
2. SWE-agent——AGENTS.md 的发明者，文化基因的源头
GitHub：SWE-agent/SWE-agent · Python · MIT
你已有的分析：你在十三份分析里反复看到 AGENTS.md / CLAUDE.md / .cursorrules——每个项目都在用自己的方式使用"一份写给 AI 看的项目说明书"。但你有没有想过——这个概念是谁发明的？为什么选择了 Markdown 文件而不是 JSON/YAML/数据库？
SWE-agent 的回答：2024 年初，SWE-agent 的团队在造编程 Agent 时发现——模型在进入一个新项目后，需要知道"这个项目怎么构建、怎么测试、有什么约定"。传统的做法是把这些信息 hardcode 在系统提示词里——但每个项目不一样。他们的创新是：让人类写一份 Markdown 文件放在仓库根目录，Agent 启动时自动读取并注入系统提示词。这个决定影响了整个 Agent 生态。
你会学到什么：
- 一个简单的设计决策是怎么扩散成行业标准的。不是因为技术有多深——恰恰是因为足够简单（任何会写 Markdown 的人都能参与）
- Markdown 作为 Agent-人类接口的利弊。简单是最大的优势（零学习成本），但缺乏结构化（Agent 可能误解、可能忽略、可能被长文件淹没）
- 和你分析过的 Codex 的 AGENTS.md 实现对照。Codex 加了 32 KiB 共享预算、AGENTS.override.md 优先、逐目录发现——这些都是在 SWE-agent 的原始概念上的"工程加固"
建议的阅读入口：
- sweagent/agent/agents.py：Agent 类的定义——看最早的 AGENTS.md 加载逻辑有多简单
- config/ 目录：SWE-agent 用 YAML 配置提示词模板——和 Claude Code 的 TypeScript 代码拼提示词是完全不同的哲学
3. LangGraph——用显式状态图代替 while 循环
GitHub：langchain-ai/langgraph · Python · MIT
你已有的分析：十三家 Agent 的核心全部是 while 循环——while True: 请求模型 → 有 tool_use 就执行 → 结果回填 → 循环。grok-build 的 Goal Mode 五件套、nanobot 的 AgentLoop 状态机——虽然有"状态"的概念，但都还是在 while 循环的框架内。
LangGraph 的回答：用显式的状态图代替 while 循环。Agent 的执行流程不是"循环直到模型说停"，而是"在节点之间按条件跳转"。每个节点是一个确定的操作（调用模型 / 执行工具 / 做判断），每条边是一个转换条件（"如果模型返回了 tool_use，跳到工具执行节点"）。
你会学到什么： - while 循环 vs 状态图——两种 Agent 流程范式的本质差异。while 循环灵活但难以预测（你不知道下一轮会发生什么），状态图确定但僵化（你必须预先定义所有可能的状态和转换） - 可恢复性和可调试性。状态图的每个节点之间都有确定的输入/输出——你可以在任意节点暂停、检查状态、从断点继续。while 循环的历史是"一条流"——你只能从头开始回放 - checkpointer（状态持久化）。LangGraph 内建了状态在每一步之后自动落盘。这和 hermes-agent 的"先落盘再动手"是同一个动机——但在状态图框架下，checkpoint 的"恰好一次"语义更自然
建议的阅读入口：
- langgraph/graph/state.py：StateGraph 的定义——理解"节点 + 边 + 状态"的三要素
- langgraph/checkpoint/：checkpoint 的实现
二、高优先级：拓宽技术视野
4. Cline——IDE 插件路线的 Agent
和已有分析的对照：你分析过的 Agent 都跑在终端里（Claude Code 的 Ink TUI、CodeWhale 的 ratatui、opencode 的 SolidJS TUI）。Cline 住在 VS Code 的侧边栏里。同一个问题（权限怎么弹窗、diff 怎么展示、上下文怎么准备）在 IDE 插件里的答案和终端 TUI 里的答案截然不同。看完 Cline 你会重新审视你分析过的所有"终端特定"的设计——哪些是 Agent 的通用需求，哪些只是"因为在终端里所以长这样"。
建议的阅读入口：src/core/ 下的任务执行和工具系统。特别看权限弹窗是怎么在 VS Code WebView 里实现的——和 Claude Code 的终端弹窗对比。
5. browser-use——浏览器 Agent 的样本
和已有分析的对照：你分析过的 Agent 的工具系统全是"操作代码"（读文件、写文件、跑命令、搜索代码）。browser-use 的工具系统是"操作网页"（点击按钮、填写表单、滚动页面、截图）。同一个主循环（模型→工具→模型），完全不同的工具集。MiroFish 是你唯一的"非编程 Agent"——browser-use 是第二个，但它的工具抽象、上下文工程（怎么把网页内容喂给模型）、停止判定（怎么判断"网页加载完了"）都跟 MiroFish 完全不同。
建议的阅读入口：browser_use/agent/service.py 的主循环——理解"浏览网页"这件事怎么被建模成工具调用。browser_use/dom/ 的 DOM 提取——理解怎么把"一个网页"变成"模型能理解的文本"。
6. Anthropic Computer Use 参考实现——用截图代替工具调用
和已有分析的对照：这是对你已有理解的终极挑战。你分析过的全部 Agent 都是"通过工具 API 操作电脑"——模型不知道屏幕长什么样，它只知道工具结果（文件内容、命令输出）。Computer Use 用截图代替一切——模型看屏幕截图，输出点击坐标和按键。没有工具定义——电脑上能显示的东西模型都能操作。"Agent harness"这个概念本身会不会被颠覆？——如果不需要定义工具就能操作任何软件，那工具系统的 15 章工程模式还有多少是必要的？
建议的阅读入口：Anthropic 的 computer-use-demo 仓库。特别看截图分辨率、坐标归一化、操作延迟——这些是 Computer Use 的"工程骨头"。
三、中等优先级：拓宽产品视野
7. AutoGen（微软）——多 Agent 对话框架
核心创新：不是"一个 Agent 干活"，而是"多个 Agent 开会讨论"。每个 Agent 有角色、能力和对话策略，通过消息传递协作。和你已有的 MiroFish 对照：MiroFish 是让 Agent 自由演化（社会仿真），AutoGen 是让 Agent 按剧本协作（工程编排）——同一个"多 Agent"概念在两个不同方向的极致实现。
8. CrewAI——角色扮演式的多 Agent 编排
和 AutoGen 对照：AutoGen 侧重自由对话，CrewAI 侧重任务编排——"研究员先搜→写手再写→审核员最后审"，更像流水线。
9. Dify——LLM 应用平台而非纯 Agent
核心看点：可视化编排——用拖拽代替写代码。和你已有分析的对照：你的所有分析都是"程序员写代码造 Agent"。Dify 是"非程序员用拖拽搭 AI 应用"。两者的 Agent 循环共享核心逻辑（模型→工具→模型），但交互层面、工程复杂度、目标用户完全不同。
10. Google A2A（Agent-to-Agent）——Agent 互操作协议
核心看点：不同供应商的 Agent 怎么互相发现、对话、协作。和你已有分析的对照：你的分析全部是"单个 Agent 内部怎么设计"，A2A 是"Agent 和 Agent 之间怎么协作"。
11. E2B / Daytona——Agent 沙箱基础设施
核心看点：沙箱即服务。Agent 通过 API 在远端沙箱里执行代码，安全隔离不归 Agent 自己管。和你已有分析的对照：Codex 自己实现了三层沙箱、nanobot 自己集成 bwrap——这些都是"Agent 项目自己管沙箱"。E2B 把沙箱做成独立产品——安全从"技术债"变成"可替换的基础设施组件"。
四、按学习路径的推荐顺序
| 如果你关注 | 先看 | 再看 |
|---|---|---|
| Agent 工程该有多"重" | Aider（极致轻量） | 回头审视你分析过的所有重型 Agent |
| Agent 文化是怎么传播的 | SWE-agent（AGENTS.md 源头） | Codex 的 AGENTS.md 实现（理解了"进化"） |
| Agent 流程的另一种写法 | LangGraph（状态图） | grok-build 的 Goal Mode（状态机在 while 循环内的实现） |
| Agent 不是只能活在终端里 | Cline（IDE 插件） | Continue.dev |
| Agent 不是只能操作代码 | browser-use（网页操作） | Computer Use（截图操作） |
| 多个 Agent 怎么配合 | AutoGen（对话式） | CrewAI（编排式） |
| Agent 怎么变成产品 | Dify（可视化编排） | — |
| Agent 之间怎么对话 | Google A2A | MCP（Agent 的工具协议） |
| Agent 的安全谁来做 | E2B（沙箱即服务） | 回头审视 Codex/nanobot 的沙箱实现 |
这个列表是活的。每当你完成一个项目的分析，可以回来更新排序。如果你时间有限但想获得最大的认知增量——先看 Aider，再看 LangGraph。前者校准"做多少"，后者校准"怎么做"。