这里记录为什么研究某个系统，不记录它是否已完成。当前完成度、缺口和发布门槛只在路线页维护；一篇文章的固定源码版本和结论范围，以文章本身及来源台账为准。Star 数、讨论热度与项目名都不能替代选题理由。
研究服务于读者的学习与应用：先能解释一个任务、选择资料和核对成果，再按兴趣理解实现。学生、老师与工具使用者的实际入口在学习与应用；下面的系统问题是可选深入，不是开始阅读的资格要求。
| 问题线 | 先问什么 | 可提供差异的系统 |
|---|---|---|
| 运行循环与工具 | 谁控制下一轮？工具何时开始、停止或失败？ | Pi、OpenCode、mini-SWE-agent、Qwen Code |
| 执行环境与权限 | 动作由谁授权、在哪里运行、如何记录副作用？ | Codex、OpenHands、Browser Use |
| 上下文、会话与记忆 | 什么真正进入本轮模型输入，什么只是被保存？ | Pi、Letta Code、Mem0、LangGraph |
| 编排与常驻系统 | 谁拥有会话，怎样聚合来源或协调执行者？ | OpenClaw、GPT Researcher、LangGraph |
一个系统可出现在多条问题线中，但每篇文章仍只证明它固定版本中的一条窄路径。概念篇解释设计空间，系统篇给来源，对照篇只比较双方已经核对的同一问题；不做“最佳 Agent”总榜。
五层职责导读已用一项任务区分模型、Harness、CLI、Skill 与 MCP。它们不是五种竞品：模型给出判断，Harness 管运行与边界，CLI 提供交互入口，Skill 装载流程知识，MCP 连接外部能力。下一波研究沿以下问题推进，而不把热门名称直接并列打分。
| 对象 | 研究层次 | 要回答的新问题 | 晋级方式 |
|---|---|---|---|
| Codex、Claude Code | 两个编码 Agent 的公开行为与用户工作流 | 同一修复任务中的项目指导、MCP、Skill、审批/沙箱如何分工？ | 使用层对照把 Codex 固定源码与 Claude Code 官方文档分开标注；不推断未公开调用栈。 |
| MiMo Code、Kimi Code | 开源 CLI + Harness | 长任务 checkpoint/重建与忙时 steer 缓冲/step 边界分别怎样做？ | 已形成各自固定 commit 的局部静态源码稿；后续核运行层时序、失败注入与二次来源。 |
| Jev | 结构化决策模型，不是编码 Agent | 有界判断怎样嵌入 Skill 选择或路由，而执行权仍留给代码？ | 已有模型/决策层旁栏；性能与正确性仍属厂商主张，未独立复现。 |
| MCP、Agent Skills、CLI 与 Harness | 协议、工作流包、界面与运行器 | 哪个层次能增加能力，哪个层次能授权执行，哪个只改变入口？ | 官方规范/文档加至少一条具体产品接入路径；安全边界与失败路径都要有。 |
| DSH / DeepSeek Harness | 插件化运行器 | 能力合同如何替换，工具完成和结果提交为什么分开？ | 固定源码切面；开发者预览的安全声明与实际策略必须一起读，不推断完整隔离。 |
| Hermes Agent | 常驻宿主中的知识维护 | 短记忆快照、按需 Skill 和任务后 review 如何分别更新？ | 固定局部实现；不把“自学习”宣称等同于权重训练或已验证效果。 |
| 沙箱与执行环境 | 资源限制、隔离层与生命周期 | Linux 容器、gVisor、microVM、E2B/Daytona 与 OpenShell 各处哪层？ | 第一方文档机制章；不把环境销毁当作副作用回滚，真实隔离实验另审。 |
| Computer / Browser Use | 观察与动作通道 | 截图、DOM/AX、CDP、原生辅助功能如何组合，结果如何验收？ | 概念章连接既有 Browser Use 固定源码；不推导运行成功率。 |
Jev、MiMo Code、Kimi Code 研究笔记保留初始问题和第一方入口；是否已成书、核验到哪一步，以各章节与路线页为准，不能用早期笔记代替现稿。
| 候选 | 值得调查的问题 | 升格条件 |
|---|---|---|
| Aider、Cline、Goose、Gemini CLI | 在循环、上下文装配、授权或工具生命周期上，是否提供与已有案例不同的取舍？ | 至少指出一个现有章节解释不了的问题，并固定可定位的源码版本。 |
| AutoGen、CrewAI、Pydantic AI | 框架提供哪些状态、委派与运行保证，哪些仍须应用自己完成？ | 先明确框架与成品 Agent 的比较边界，避免直接拿不同层次排功能榜。 |
| OpenAI Agents SDK、Google ADK、AgentScope | 框架的循环、交接、工具、会话和评测各由谁负责？应用还必须补哪些部署与远端副作用协议？ | 优先选择一个与现有 LangGraph 切面形成明确设计对照的路径；先固定源码与官方文档，不以“框架功能表”凑系统数。 |
| Letta 历史服务 | 旧版 memory blocks 与当前 Letta Code local MemFS 有何连续或断裂？ | 核对仓库维护状态与版本；只作历史对照，不把旧实现标作现行架构。 |
| WorkBuddy 等闭源工具的使用路径 | 对同一任务，项目指令、工具接入、审批与交付证据在用户界面上如何呈现？ | 先确认具体产品与官方资料，再用获授权的环境记录可复现实操；只写公开行为，不猜内部架构。 |
新增剖面按系统模板写一个可证伪的问题，固定仓库、commit、关键文件、核对日期与许可，再决定是否需要主图和第二篇。找不到可靠来源或只重复已有解释时，保留为候选，不为凑热门名单扩书。闭源产品只能据官方公开资料作边界清晰的参考，不能写成开源源码剖面。
具体怎样从“读懂机制”走到“能完成一项任务”，以及哪些候选先写、哪些延后，见学习内容扩展计划。这是一份选题和验收安排，不是已发表章节清单。