请求线
输入经过哪些组装步骤，最终变成 system、messages、tools 和模型参数？
系统总览
Coding Agent 到底是什么？
它不是“会写代码的聊天机器人”，而是一个由模型驱动、能观察环境、调用工具、记录状态并持续推进任务的运行系统。模型负责决定下一步；Harness 负责把这一步变成受约束、可恢复、可追踪的真实行动。
模型负责决策根据当前请求生成文本或工具调用。
Harness 负责执行组装上下文、执行工具、处理取消与权限。
日志负责连续性让恢复、回放和压缩仍能重建模型所见。
问题 01
一次任务在系统里怎样流动？
答案：输入先进入 Agent 的收件箱；运行循环认领输入并组装模型请求；模型可能返回工具调用；工具结果写回会话后，模型再基于新事实继续推理，直到给出不含工具调用的最终回答。
在仓库中验证
问题 02
它与普通聊天机器人差在哪里？
答案：差别不主要在模型，而在模型外面的执行系统。聊天机器人通常只生成回复；Coding Agent 还必须把意图转成操作，观察操作结果，管理长任务状态，并在失败、取消或恢复后保持一致。
| 能力 | 普通聊天 | Coding Agent |
|---|---|---|
| 输出 | 主要是自然语言 | 自然语言 + 结构化工具调用 |
| 环境 | 依赖对话里已有的信息 | 主动读取文件、运行命令、检索与修改 |
| 控制流 | 一次请求通常结束一轮 | 一次 Turn 可包含多个模型 Step 与工具批次 |
| 状态 | 消息列表足以覆盖很多场景 | 需要事件日志、请求头、工具结果和生命周期记录 |
| 安全 | 限制生成内容 | 还要限制真实副作用、路径、进程与权限 |
问题 03
理解这个 Agent，需要拆成哪些知识模块？
答案：可以把系统分成五个互相连接的问题域：谁推进任务、模型看见什么、动作怎样执行、异常怎样被收住、复杂工作怎样拆给其他执行单元。它们共同围绕会话日志和插件扩展点工作。
问题 04
读源码时，应该持续追踪什么？
答案：不要按目录逐个扫包。沿着同一个行为同时追三条线：它怎样进入模型请求、它造成了什么副作用、它怎样写入日志并在恢复时重建。三条线能闭合，才算真正理解一个 Agent 特性。
副作用线
工具在哪里被准入、执行、取消和收尾？真实环境由谁拥有？
重建线
哪些事件足以重放同一历史？中断后如何得到相同的下一次请求？
判断标准：如果只能解释某个函数做了什么，却不能说明它在请求、副作用与日志中的位置，理解仍停留在局部实现。
适合作为入口的组装实例