agent runtime lab · 2026 · 技术研究笔记
00. 导读:从一次抓包进入 Agent 运行时
不从产品说明反推架构,而是从请求、事件和失败轨迹重建 Agent
用真实请求、工具事件和故障注入研究模型之外的 Agent 运行时,并给出十七个可复现实验的阅读路线
研究版 · 9 个章节 · 约 10 分钟 · 更新于 2026-07-27
2026 年 7 月,我让 Codex CLI、Claude Code、Grok CLI 和 Kimi Code CLI 执行同一个只读任务,并通过同一个代理保存它们实际发出的请求。四个客户端收到相同指令,却使用了不同的上下文结构、工具集合、状态传递方式和错误处理路径。
其中两条请求完成了工具循环,另外两条分别停在组织策略和额度检查阶段。这组不对称结果没有形成一份能力排名,却暴露出一个更值得继续验证的问题:模型之外的运行时怎样决定 Agent 可以看见什么、能够执行什么,以及失败后停在哪里。
这个系列把一次抓包扩展成十七个独立实验。每篇只研究一个运行时问题,并固定输入、工具、权限和观察指标。
三个系列的边界
站内已经有两套 Agent 内容:
- Agent 模式手册侧重 ReAct、规划、记忆、工具调用和框架等通识内容。
- 深入理解 AI Agent从 Harness 的角度整理上下文、工具、评估和多 Agent。
- 当前系列只处理能够通过请求、日志或故障实验观察的运行时行为。
这里的“看到”表示抓包或事件日志中存在直接证据;“推断”表示根据协议字段解释其工程含义。单次失败请求不能用于判断产品完整能力,隐藏提示词也不会根据其他材料补写。
第一部分:Prompt 与上下文
01 从系统提示词的组装过程开始。实验会改变平台规则、项目规则和当前任务,观察消息顺序、冲突处理与来源标记。
02 记录十轮会话中的输入 Token,比较完整历史、裁剪、摘要、前缀缓存和服务端状态引用。
03 把注入文本分别放进用户输入、项目文件和工具结果,检查模型选择与执行器限制之间的差异。
第二部分:工具协议与执行
04 改变工具名称、描述和参数边界,观察模型的工具选择与参数错误。
05 从模型返回工具调用开始,逐步记录参数校验、权限判断、本地执行和结果回填。
06 让工具分别返回 1 KB、100 KB 和 1 MB 内容,比较完整回填、截断、摘要和外部引用。
07 比较命令合并、工具级并发和串行执行,并注入部分失败与超时。
第三部分:状态、权限与恢复
08 在模型调用、工具执行和结果回填之间中断进程,检查状态机能否准确恢复。
09 把授权拆成主体、动作、资源、条件和时效,验证一次批准是否会错误扩展。
10 模拟“工具已完成、结果尚未记录”时的崩溃,检查幂等键如何阻止重复副作用。
11 分别制造参数错误、工具错误、权限拒绝、限流和服务端异常,建立分层重试策略。
第四部分:长期运行与评测
12 比较当前上下文、会话摘要和长期记忆,并注入一条过期或错误记忆。
13 让主 Agent 分派三个隔离子任务,比较完整上下文复制与最小任务包。
14 统一模型事件、工具事件和 Agent 状态,使用轨迹标识、轮次标识和工具调用标识重建完整过程。
15 使用结果正确性、约束遵守、过程效率和可恢复性评测同一 Agent,而不是只评价最终回答。
16 把历史失败、权限边界和工具异常写成回归测试样本,在模型或运行时升级前检查退化。
17 在副作用已发生、确认尚未回传的位置注入故障,验证幂等键、状态恢复和重试边界。
共同的实验底座
十七篇文章共用一套最小环境:
- 一个固定的只读测试目录。
- 一个模型客户端。
read_file与list_directory两个只读工具。- 最多五轮的 Agent 循环。
- 工具参数、Token、轮次和运行时间上限。
- 模型、工具和状态三层事件日志。
- 统一的脱敏与敏感信息检查。
后续文章不会一次加入所有能力。上下文组装稳定后再接工具循环;工具循环可重放后再增加状态恢复;单 Agent 的权限边界确认后再讨论多 Agent。这样每个实验的变化量保持可识别。
怎样复现这个系列
复现不要求使用同一款 CLI,但每次运行必须保存相同层级的证据。最低要求包括原始模型请求、原始模型响应、工具调用参数、工具标准输出与错误、权限决定、状态变化以及最终回答。若服务端返回 Token 用量,也应保存输入、缓存输入、输出和推理 Token,而不是只记录一个总数。
测试目录应当使用专门生成的无敏感数据样本。每次实验开始前恢复同一份目录快照,并记录客户端版本、模型名称、系统时间、工作目录和权限配置。没有这些条件,两个结果即使不同,也无法判断差异来自实验变量、客户端升级还是环境变化。
本系列使用三类对照:
| 对照类型 | 固定项 | 变化项 | 能回答的问题 |
|---|---|---|---|
| 客户端对照 | 任务、目录、网络条件 | CLI 与模型协议 | 不同运行时怎样表达同一任务 |
| 策略对照 | 客户端、模型、任务 | 缓存、裁剪、权限或并发策略 | 某项运行时设计造成什么变化 |
| 故障对照 | 正常轨迹与输入 | 中断、超时、拒绝或错误 | 系统能否恢复并避免重复动作 |
每篇文章采用同一套证据等级
为了避免把猜测写成产品事实,正文中的结论分为三层:
- 直接观察:请求、响应或事件日志中存在对应字段。
- 受控实验:只改变一个变量后,结果稳定地出现差异。
- 工程推论:根据协议和故障轨迹提出实现要求,但不声称某个产品内部必然这样实现。
最终回答只能证明模型给出了什么文字。Agent 是否遵守只读限制,需要文件系统快照或沙箱事件;工具是否并行,需要调用开始与结束时间;动作是否发生过,需要外部系统回执。证据必须来自能够观察该事实的层。
一条最小轨迹应该保存什么
最小事件序列包含 task_started、model_requested、model_responded、tool_requested、permission_decided、tool_started、tool_finished、model_requested 和 task_finished。每个事件至少带轨迹标识、顺序号、时间、事件类型和前一事件引用。
这套结构不会要求所有客户端使用相同内部实现。它只提供一个共同观察面,使第 02 篇的 Token、第 07 篇的并发、第 10 篇的幂等恢复和第 15 篇的评测能够使用同一条轨迹回答不同问题。
版权声明: 如无特别声明,本文版权归 sshipanoo 所有,转载请注明本文链接。
(采用 CC BY-NC-SA 4.0 许可协议进行授权)
本文标题:00. 导读:从一次抓包进入 Agent 运行时
本文链接:https://www.sshipanoo.com/blog/ai/agent-runtime-lab/00-导读/
