模型 API 请求
Model provider request
Harness 到模型提供商之间的一次完整往返。Harness 发送当前上下文，提供商返回一个响应（一次工具调用或最终答案）。如果 Agent 调用了工具，一条用户消息可能产生多次模型请求——每次工具结果都会触发下一次请求。
每次请求都携带全部内容：System Prompt、到目前为止的完整对话、所有工具结果。模型是无状态的，因此提供商不会在请求之间保留任何东西——第四十次请求会重发第三十九次请求的全部内容，再加上一个新的工具结果。前缀缓存的存在正是为了让这种重复变得可负担。
请求也是计费的单位。输入 Token、输出 Token 和缓存折扣都按请求统计，所以一个看起来普通的问题可能花费惊人：成本不与你的消息长度成正比，而是与请求次数乘以每次请求所携带的上下文大小成正比。
要注意把请求和轮次区分开。一轮次是你和 Agent 的一次交互，而单轮次——比如“修复这个失败的测试”——会展开成一串请求：
| 请求 | 模型返回 | Harness 随后 |
|---|---|---|
| 1 | 工具调用：运行测试 | 运行测试，追加失败输出 |
| 2 | 工具调用：读取测试文件 | 追加文件内容 |
| 3 | 工具调用：读取源文件 | 追加文件内容 |
| 4 | 工具调用：编辑源文件 | 应用编辑，追加结果 |
| 5 | 工具调用：再次运行测试 | 运行测试，追加通过输出 |
| 6 | 最终答案：“已修复，测试通过” | 展示给你 |
一轮次产生了六次请求——每一次都重发整个上下文。当你纳闷 Token 都花在哪时，数的是请求数，不是轮次数。
用法：
“一个问题烧了四万 Token？”
“看这些工具调用——十二次 grep、八次读取、四次编辑。每次工具结果都会触发新的模型请求，而且整个 Session 的前缀每次都要重发。”