Session 0002

Agent Harness 运行时设计

Agent harness 是把模型、工具、状态、策略、预算、追踪和人工介入组织成可运行系统的控制层。这里的训练目标不是会调 API，而是能把 agent 做成可恢复、可观测、可控成本、可上线的运行时。

1. 训练目标

本页要练会：把一个开放式 agent 需求拆成 runner、state、tool、policy、memory/context、trace/eval、HITL 七个工程模块，并能解释每个模块的失败模式。

可靠依据：OpenAI Agents SDK / LangGraph persistence / Anthropic tool use。本页把官方能力和生产工程约束转成面试题，而不是堆概念定义。

题量标准：5 个中大型深题 + 7 个知识广度题。深题用于系统设计和追问承压，广度题用于查漏补缺。

2. 五个深题

深题 01

你要从零设计一个客服 agent runtime，支持查订单、申请退款、解释政策和转人工。核心模块有哪些？

考察点：面试官在判断你是否理解 agent 不是一次模型调用，而是一个受控循环。必须讲清 observe → decide → act → observe → stop 的 run loop，以及谁负责预算、状态、工具、策略和恢复。

7+ 分回答骨架：高分答案先拆 runner、state store、tool registry、policy gate、context builder、trace/eval hook、human escalation。查订单是 read tool，可重试；退款是 side-effect tool，需要幂等键、审批、审计和恢复点。runner 控制 max step、timeout、cost、risk budget，policy gate 在工具执行前拦截越权和高风险动作。

继续追问会衍生：衍生知识点：stop condition、step budget、side effect、idempotency、trace replay、approval state。

知识展开

概念是什么工程落点面试表达 / 常见坑
stop condition停止条件不是“模型说结束”这么简单，而是 runner 判断任务已完成、预算用尽、风险升高、重复循环或需要人工介入。放在 runner 层，结合 max_steps、max_cost、tool_result_hash、risk_level、final_answer_schema 判断是否继续。面试里要说模型可以建议 final，但最终是否停止由 harness 控制。只说 max token 会显得不懂 agent loop。
step budgetstep 是一次模型决策或工具动作。预算控制的是行动次数、成本、延迟和风险，而不只是 token。RunConfig 中配置 per-run、per-tool、per-risk-level 的 step/time/cost 限制，trace 记录每一步消耗。强回答要能解释为什么退款、发邮件这类高风险动作的 step budget 应该更紧。
trace replaytrace replay 是用历史输入、工具结果、版本信息复现一次 agent 路径，定位到底是 prompt、工具、状态还是模型变化导致失败。trace 必须保存 prompt/model/tool schema/policy/index version、tool args/result、state diff。如果没有 replay，线上坏 case 只能靠猜，无法变成回归 eval。
深题 02

Agent 连续调用同一个工具停不下来，线上成本飙升。你怎么定位和治理？

考察点：考 loop 控制和 observability。不能只说 max token 或换模型。

7+ 分回答骨架：先从 trace 看重复调用是否参数相同、tool result 是否未进入 state、模型是否看不到失败原因、prompt 是否鼓励继续尝试。治理上设置 max steps、per-tool quota、same-args dedupe、state diff 检测、semantic loop detector、budget guard 和 fallback。对写工具还要用幂等键防重复副作用。

继续追问会衍生：衍生知识点：loop detection、tool result compression、state mutation、budget guard、fallback path。

知识展开

概念是什么工程落点面试表达 / 常见坑
loop detection循环检测要判断 agent 是否在重复同一意图、同一工具、同一参数或无状态变化地继续行动。runner 比较最近 N 步的 tool name、args hash、result summary、state diff 和模型理由。面试表达：max_steps 是最后保险，真正治理要识别重复模式并给 fallback。
tool result compression工具结果不能原样无限塞回 prompt，要压缩成当前决策需要的结构化摘要，同时保留原始结果在 state。adapter 输出 concise summary、key fields、source ids、pagination token，context builder 再决定放多少。常见坑是把 200 条结果全塞 prompt，导致上下文污染、成本升高、模型抓错重点。
fallback pathfallback 是原路径不可继续时切换到可控路径，不等于简单重试。例如工具超时后转人工、只给政策解释、不执行退款、或切到只读模式。强回答要区分 retry、fallback、escalation：三者触发条件和风险不同。
深题 03

一个 agent 任务需要用户审批，审批可能隔天才回来。harness 如何暂停和恢复？

考察点：考持久化状态，而不是靠聊天历史。

7+ 分回答骨架：把任务建模为 durable state machine：保存 task_id、thread_id、current node、pending approval、tool args draft、risk summary、trace id、version。暂停时不继续调用模型；审批回来后校验审批人和 state version，再从同一节点 resume。任何外部写动作必须可幂等或有补偿动作。

继续追问会衍生：衍生知识点：durable execution、approval token、state version、resume semantics、compensation。

知识展开

概念是什么工程落点面试表达 / 常见坑
durable execution长任务不能靠聊天历史维持进度，而要把执行状态持久化，允许暂停、恢复、重跑和审计。保存 task_id、current_node、pending_approval、tool_draft、state_version、trace_id。面试里说“审批回来从同一节点 resume”，比“让模型继续聊”更像生产系统。
approval token审批不是一句用户确认，而是可验证的授权事件，包含审批人、范围、过期时间和绑定的动作摘要。approval token 绑定 tool args hash、risk summary、approver id、expires_at，执行前重新校验。常见坑是用户说“确认”就执行，但确认内容可能已经和当前参数不一致。
compensation补偿是写操作失败或部分成功后的反向动作或人工修复流程，不是所有动作都能简单 rollback。支付、发邮件、外部提交要设计 status query、cancel/refund/revoke 或人工工单。强回答要先说幂等，再说状态查询，最后说补偿，不要直接盲目重试。
深题 04

如何设计 agent 的状态层，避免“所有东西都塞 prompt”？

考察点：考 context 与 state 分层。

7+ 分回答骨架：状态分 conversation messages、task state、tool results、retrieved evidence、memory candidates、policy decisions、approvals、audit log。prompt 只装当前决策必要的投影，不是完整数据库。状态层用于恢复、审计和 eval；context builder 按任务读取最小必要视图。

继续追问会衍生：衍生知识点：source of truth、context projection、state store、prompt packing、auditability。

知识展开

概念是什么工程落点面试表达 / 常见坑
source of truthsource of truth 是系统认可的真实状态来源。agent 的 prompt 只是投影，不是事实库。订单状态来自订单服务，审批状态来自 workflow store，工具结果来自 state store。面试中要明确：模型不能凭记忆决定订单是否退款成功，必须查权威系统。
context projectioncontext projection 是从完整状态中选出本轮决策需要的一小部分放入 prompt。context builder 按任务、风险、token budget、权限过滤 state、memory、tool results。常见坑是把所有状态放 prompt，导致过长、泄露和不可控。
state storestate store 保存结构化任务状态，支持恢复、审计、eval 和跨步骤一致性。至少包含 run_id、thread_id、task_state、tool_results、approvals、policy_decisions、errors。强回答要说明 state store 和 memory store 不同：前者是任务执行状态，后者是长期可复用信息。
深题 05

如果你要让多个业务团队共用同一个 harness，哪些接口必须抽象？

考察点：考平台化能力。

7+ 分回答骨架：抽象 AgentSpec、ToolSpec、PolicySpec、MemorySpec、EvalSpec、TraceSchema、RunConfig。业务团队配置工具、权限、模型、prompt 和风险规则；平台提供 runner、state、budget、trace、eval、release gate。工具接口要有 schema、auth context、risk level、idempotency、timeout 和 error taxonomy。

继续追问会衍生：衍生知识点：platform boundary、tool contract、policy-as-code、versioning、multi-tenant quota。

知识展开

概念是什么工程落点面试表达 / 常见坑
tool contract工具契约规定模型能请求什么、服务端会校验什么、返回什么结构，以及失败如何表达。ToolSpec 包含 schema、required fields、risk level、timeout、idempotency、auth scope、error taxonomy。面试里不要只说“注册工具”，要说工具契约如何保护系统边界。
policy-as-code策略不能散落在 prompt 里，要以代码或配置执行，保证可测试、可审计、可回滚。例如 refund_amount_limit、approval_required、tool_allowlist、tenant_scope 都在 policy engine 中判定。常见坑是把安全规则写进 system prompt，模型被诱导时仍可能越权。
multi-tenant quota多租户系统要限制不同团队、用户或业务线的调用量、成本和风险动作频率。按 tenant/feature/model/tool 设置 rate limit、cost cap、concurrency、risk quota。强回答要能把平台化 harness 和单业务 demo 区分开。

3. 七个广度题

编号问题准确回答
广度 01Runner 和 planner 是一回事吗？不是。runner 是确定性的执行控制器，planner 是模型或规则生成下一步计划的组件。runner 必须能拒绝 planner 的危险动作。
广度 02为什么 tool result 要结构化保存？为了恢复、回放、eval、去重和错误分类；只保存自然语言会丢失状态和机器可判定字段。
广度 03max token 能不能防止 agent 无限循环？不能。循环是 step/action 层问题，要用 max step、预算、重复检测和 stop rule。
广度 04什么时候必须 human-in-the-loop？高金额交易、权限变更、外部提交、法律风险、低置信但高影响决策。
广度 05Agent harness 的 trace 至少记录什么？run id、step、prompt/model/schema version、tool args/result/error、policy decision、latency、cost、final answer。
广度 06为什么不要让模型传 tenant_id/user_role？身份和权限必须来自服务端 auth context，模型参数不可信。
广度 07怎么区分 retry 和 fallback？retry 是同一路径再次尝试，fallback 是降级到另一路径，如小模型失败转人工或跳过非关键 enrichment。

4. 知识索引

stop condition

停止条件不是“模型说结束”这么简单，而是 runner 判断任务已完成、预算用尽、风险升高、重复循环或需要人工介入。

step budget

step 是一次模型决策或工具动作。

trace replay

trace replay 是用历史输入、工具结果、版本信息复现一次 agent 路径，定位到底是 prompt、工具、状态还是模型变化导致失败。

loop detection

循环检测要判断 agent 是否在重复同一意图、同一工具、同一参数或无状态变化地继续行动。

tool result compression

工具结果不能原样无限塞回 prompt，要压缩成当前决策需要的结构化摘要，同时保留原始结果在 state。

fallback path

fallback 是原路径不可继续时切换到可控路径，不等于简单重试。

durable execution

长任务不能靠聊天历史维持进度，而要把执行状态持久化，允许暂停、恢复、重跑和审计。

approval token

审批不是一句用户确认，而是可验证的授权事件，包含审批人、范围、过期时间和绑定的动作摘要。

compensation

补偿是写操作失败或部分成功后的反向动作或人工修复流程，不是所有动作都能简单 rollback。

source of truth

source of truth 是系统认可的真实状态来源。

context projection

context projection 是从完整状态中选出本轮决策需要的一小部分放入 prompt。

state store

state store 保存结构化任务状态，支持恢复、审计、eval 和跨步骤一致性。

tool contract

工具契约规定模型能请求什么、服务端会校验什么、返回什么结构，以及失败如何表达。

policy-as-code

策略不能散落在 prompt 里，要以代码或配置执行，保证可测试、可审计、可回滚。

multi-tenant quota

多租户系统要限制不同团队、用户或业务线的调用量、成本和风险动作频率。

5. 巩固训练

练习要求自检
8 分钟口述任选一个深题，先给架构，再讲风险、指标、恢复和上线。是否覆盖状态、权限、失败、eval、成本或延迟。
追问压缩把每个深题的回答压缩成 5 句话。每句话必须包含一个工程事实，不能是空泛判断。
反例修正先故意给一个弱回答，再补齐缺失模块。能否说出弱在哪里，以及如何验证强答案。

6. 弱回答红线