1. Agent 评测和「一问一答」评测有什么不同

传统 LLM Eval（例如 QA、翻译、选择题）通常是：

Agent 场景则往往是 多步决策：

典型循环叫 ReAct（Reason + Act）：

Agent Harness 的核心目标不是「最后一句话像不像标准答案」，而是：

给定 Task + Tool Set → 自动执行 → 记录完整轨迹 → 自动打分 → 可回归对比

因此需要记录的不只是 final_answer，而是 整条 decision chain。

---

2. Trajectory：为什么要持久化、可回放

Agent 交互往往是 multi-step。Harness 需要把每一步结构化存下来，形成 trajectory。

单步 schema 示例：

完整 trajectory 还包括：run_id、task_id、model、max_steps、final_answer、steps[] 等。

为什么要存盘

持久化之后可以：

1. 离线回放 —— 不必重调 API，直接读 JSON/JSONL
2. 自动打分 —— 从 steps 算 success、misuse、loop、cost
3. 回归测试 —— 对比两次 run 的轨迹与指标

Trajectory schema 是 Agent 评测的「通用语言」：先定义格式，再写 runner、metrics、report。

---

3. Tool 评测：expected vs actual

Agent 除了最终答案，还要评 工具调用是否正确。

每步 tool 调用约定为：

比对逻辑是 结构化字段匹配，不是简单字符串相等：

三个核心指标：

三种典型 Tool Misuse

这是 rule-based 批改：name + args 精确匹配（加少量 normalize），不是语义理解。

---

4. Tool Schema 和 Tool 执行函数是两回事

Function Calling 体系里必须分清两层：

4.1 Tool Schema（给模型看的「菜单」）

这是 JSON 元数据，传给 API 的 tools= 参数。
它 不能执行，只告诉模型：有哪些工具、各需要什么参数。

4.2 Tool 执行函数（本地真正干活的代码）

模型 永远不会直接调用 这个 Python 函数。流程是：

模型决策，代码执行 —— 这是 FC 的安全与可控基础。

---

5. function_call vs tool_calls（OpenAI 兼容 API）

新版结构示例：

回传 tool 结果时必须对应 id：

新代码应统一使用 tools= + tool_calls，不再使用 function_call。

---

6. Agent Runner：run_fc_loop 在做什么

Agent Runner 的职责：把 task + tools 跑成标准 trajectory，而不是追求最强 Agent 能力。

run_fc_loop 本质是 orchestration 循环（不是模型「自我调用」）：

三个角色分工：

---

7. 为什么 Function Calling 通常至少两轮 API

这是 FC 的 必要设计，不是实现冗余。

若只有一轮：

• 不调 tool → 容易幻觉
• 调了 tool 但看不到结果 → 无法 grounded 回答

因此 「一轮要 tool + 一轮给答案」 是标准两阶段。
复杂任务会更多轮：多次 tool 调用 + 最后一次生成答案。

Trajectory 里的 步数 通常统计的是 API 轮次 / 决策步，不等于「同一个 tool 被执行了几次」。

---

8. 死循环检测：detect_loop

Agent 常见故障之一是 重复调用相同工具：

最小检测规则：

Runner 中一旦发现 loop，应：

• 设 loop_detected = True
• 强制 break，避免无限烧 token

另一种失败模式：跑满 max_steps 仍无 final_answer，也可视为 timeout / loop 类失败。

---

9. Agent Harness 六层架构（串联）

数据流：

---

10. 核心结论

1. Agent ≠ Chatbot：评测对象是 multi-step 决策链，不是单句 output。
2. Trajectory 是 Agent Eval 的增量：可审计、可回放、可回归。
3. Tool 评测是结构化匹配：name + args，外加 misuse / accuracy 指标。
4. Schema ≠ 函数：模型看 menu，代码做 execution。
5. FC 至少两轮 API：先 tool、再 answer，是协议设计而非浪费。
6. Runner 是编排层：循环驱动 LLM ↔ Tool，并负责 loop 截断与日志。
7. tool_calls 取代 function_call：多调用、可追踪、可扩展。

以上构成 Agent Harness 的最小技术栈：不依赖特定框架（LangGraph、MCP 等），用 schema + loop + trajectory + rule metrics 即可搭建可测试、可度量的 Agent 评测流水线。