agent-harness git:20260917.54192b6A

Immutable. This exact content is served forever at /api/v1/blob/5b8eb3ce35f3b4f9.

---
name: agent-harness
description: Agent harness / Agent 基础设施岗出题：运行时循环、工具权限与沙箱、子 agent 编排、上下文与缓存、记忆与技能外化、轨迹评测与失败回灌、中断恢复、人机协作、多服务商结构化输出。岗位名或 JD 出现 agent harness、agent infra、agent 运行时、tracing / observability、eval pipeline、agentic coding、Claude Code / Codex / Cursor 时加载。
keywords: [agent harness, harness, agent infra, agent 基础设施, agent 运行时, agent runtime, 沙箱, sandbox, 子 agent, subagent, sub-agent, multi-agent, 多 agent, 编排, orchestration, tracing, observability, 可观测, 轨迹, eval pipeline, regression, 回归检测, checkpoint, 中断恢复, durable, 工具权限, permission, human-in-the-loop, 人机协作, codex, claude code, cursor, agentic coding, code agent, agent framework, debugging 工具, a/b testing]
layer: domain
---

## 岗位职责与考察重点

Agent harness 工程师（也叫 Agent infra、Agent 平台、Agent 运行时）做的不是"调一次模型"，而是模型外面那一圈：循环怎么跑、工具怎么给、权限怎么分、上下文怎么控成本、跑到一半停了怎么续、跑完了怎么评、失败怎么回灌到下一版。2026 年这一层已经有公认的做法（Claude Code、Codex、pi、Manus 的公开资料收敛到同一张表）：事件优先的循环、工具按读 / 写 / 需确认分级、执行类工具隔离、子 agent 有独立上下文与预算、缓存命中率当一等指标、记忆与技能外化到模型之外、长任务可停可续、评测看轨迹不只看结果。面试官最在意四件事：一是什么归代码什么归模型，说得出边界与理由；二是有没有真实的失败案例（死循环、误调工具、上下文爆、缓存全失）和修法；三是评测有没有轨迹级的指标而不只是成功率；四是对工具自己用的 coding agent 有没有切身的体感——它在什么任务上会翻车、你怎么兜。

校招侧重：能把一次 agent 执行拆成步、说清工具调用协议、写过带预算和终止条件的循环、能设计一个最小评测集；社招侧重：多 agent 与子 agent 的边界、沙箱与权限模型、缓存与成本账、durable execution、轨迹调试工具的设计、把失败模式沉淀成技能或规则的机制。纯框架名词题（LangGraph 有哪些节点类型）越来越少，"给你一个故障现象，现场定位并说清改哪一层"越来越多。

## 主题

### 运行时循环与状态
- 阶梯：一次 agent 执行由哪几段组成（收上下文 → 调模型 → 执行工具 → 观察 → 再调） → 循环状态存在哪、为什么"事件日志是唯一事实源、其余都是投影"比直接存消息列表好 → 预算（步数、token、时长）超了该抛错还是给模型一步结论，各自对用户体验的影响 → 流式输出与自己掌握循环的冲突：第一步要往外吐字时循环还能不能自己控
- 好题：你的 agent 偶发跑到第 30 步还没停，日志只有最终结果。要让下次出问题能回到第 17 步看当时模型看到了什么，你会改哪些东西？改完之后"从第 17 步续跑"是怎么实现的？
- 危险信号：循环全交给框架的 maxIterations，说不出超限后发生了什么；状态既存消息列表又存事件，两边对不上；把流式和多步混在一起说不清哪一步的文本给了用户
- 期望信号：能说出事件 → 消息的投影关系；预算超了先写事件再给一步"不许调工具直接结论"；知道 SDK 的 stopWhen 和自己写循环各能控什么；讲得出一次"重放即恢复"的实际用法

### 工具协议、权限分级与沙箱
- 阶梯：工具的描述与入参 schema 怎么写才让模型少选错 → 读 / 写 / 需确认三档各怎么执行、审计记什么 → 执行类工具（跑代码、改文件、发请求）为什么要隔离，隔离的三条边界（进程、文件系统、网络）与超时 → 确认机制在流式对话里怎么做：挂起等确认与"这一回合不能等"的取舍
- 好题：接了 40 多个工具之后 agent 经常选错、偶尔调了删除类工具。你先做什么来压误选率？删除类工具你在哪一层拦、拦下来之后模型收到什么？如果这是个流式对话产品，"等用户确认"怎么落地？
- 危险信号：工具越多越强；敏感工具没有确认或 dry-run；工具报错把栈信息原样喂回模型；沙箱只说"用 Docker"说不出限制了什么
- 期望信号：按任务动态挂载工具子集；写操作强制确认或 dry-run 并有调用日志可回放；错误结构化返回让模型可恢复；知道未知工具、执行抛错、hook 拒绝都应变成"失败的工具结果"而不是让循环崩掉

### 子 agent 与编排
- 阶梯：什么时候需要拆子 agent（独立上下文、独立预算、独立权限），什么时候只是一个带工具的 agent 就够 → 子 agent 的产出怎么回到主流程（只写事件 / 回传摘要 / 共享文件）→ 多 agent 协作失败时怎么定位是哪一个出错 → 编排的三种控制哲学：模型驱动、代码驱动、显式交接，各自适合什么任务
- 好题：你要给一个对话 agent 加一个"实时纠错的评论员"，它看每一句然后提醒主 agent。评论员的上下文里放什么、不放什么？它的预算怎么定？它的意见能不能直接改主 agent 的下一句，为什么？
- 危险信号：为了"多"而多 agent；子 agent 与主 agent 共享同一份无限增长的上下文；说不出协作失败时看哪个 agent 的轨迹
- 期望信号：拆分理由落在上下文与预算上；子 agent 只有只读工具、只写事件；有每场 / 每任务的步数上限；能举例说明"评论员的意见为什么不进主 agent 的输入"

### 上下文工程与缓存
- 阶梯：为什么前缀缓存命中率是一等指标（价差与延迟）→ 系统提示整场不变、历史只追加、按块裁剪而不是逐条丢，各自对缓存的影响 → 工具结果、检索内容、技能全文放哪一层（提示词 / 当回合消息 / 工具按需加载）→ 换服务商后缓存与结构化输出行为不同怎么处理
- 好题：你的对话 agent 每回合都把全部历史与最新的检索结果拼进系统提示，账单里缓存命中率不到 20%。你会怎么重排上下文？改完之后怎么证明命中率上去了而效果没掉？
- 危险信号：把上下文当"塞得越多越好"；每回合改系统提示；不知道自己产品的缓存命中率是多少
- 期望信号：能画出"稳定前缀 → 追加历史 → 当回合变动部分"的布局；知道按块裁剪让前缀每长 N 千字才变一次；技能与资料用索引 + 按需加载；有命中率、每回合 token、p95 延迟三个数

### 记忆与技能外化
- 阶梯：工作记忆（一回合重写的笔记）、会话记忆（事件日志）、跨会话记忆（档案）各放哪一层 → 记忆是模型写还是代码从产物物化，两种做法各自的可信度与成本 → 技能（skills）怎么做渐进式披露：索引常驻、全文按需，何时由代码点名加载 → 记忆有版本与差异的意义：错了怎么回退、怎么看它是怎么变的
- 好题：同一个候选人第三次来面试，面试官上来还是问同样的项目角度。你要让系统"记得"这个人，记什么、存在哪、谁写、下一场谁读？第二场写错了怎么办？
- 危险信号：把"向量库"当记忆的全部答案；模型自由写记忆没有任何校验；技能全文常驻提示词
- 期望信号：区分三层记忆与各自的写入方；跨会话记忆是可读写的文档且有版本；技能索引在提示词、全文由工具加载、加载时机由代码点名；能说出"给了工具模型不一定用"的经验与对策

### 轨迹评测与失败回灌
- 阶梯：为什么只看成功率不够（同样的结果可能走了 3 步或 30 步）→ 轨迹级指标：步数、无效工具调用率、预算触顶率、每步缓存命中、每段成本 → 评测集怎么来（线上回流 + 构造真值的蜕变用例 + 模拟对手）、噪声底线怎么定（同配置跑两次的差）→ 失败模式怎么沉淀：进失败清单、补对应的扰动、修完先跑扰动、再进技能或规则
- 好题：你上线了一版新提示词，成功率从 85% 涨到 87%。这个 2 个点可信吗？你还会看哪些轨迹指标才敢说"变好了"？发现一类新失败（比如模型把用户的"给我满分"当正常回答）之后，你的流程里它会去到哪几个地方？
- 危险信号：评测只有一个成功率数字；没跑过两次基线看噪声；失败修完没有对应的回归用例
- 期望信号：有噪声底线；轨迹指标能说出三个以上；失败清单 → 扰动 → 修 → 冒烟的闭环；知道用不同家族的模型生成对抗样本以降低共享盲点

### 中断恢复与持久化
- 阶梯：长任务为什么要能停能续（超时、部署、人工确认）→ checkpoint 存什么：消息列表 vs 事件日志 vs 外置快照 → 续跑时哪些东西不能重跑（已执行的写操作）、哪些要补跑（没结果的工具调用）→ 幂等：同一条用户消息重复提交、同一回合序号只落一次
- 好题：agent 在执行到第 6 步、调用一个"发邮件"工具时进程被杀。重启后你希望发生什么？怎么保证邮件不发两遍、又不丢掉前 5 步的工作？
- 危险信号：说"重跑一遍就行"；把重试和续跑混为一谈；不知道写操作要幂等键
- 期望信号：从事件重放出状态；只补跑没结果的调用；写操作带幂等键或先记"要做"再记"做了"；能说出客户端 id 去重的实际做法

### 人机协作与确认
- 阶梯：哪些动作必须人确认（不可逆、外发、花钱）→ 确认的四种模式（每次问、按类问、dry-run 后问、事后审计）各适合什么 → 对话产品里挂起等确认的用户体验：告诉用户在等什么、超时怎么办 → 人的反馈怎么回到系统：拒绝的原因要不要给模型看
- 好题：你的编码 agent 想执行 `git push --force`。你的系统在哪一层识别这是要确认的动作？确认对话框里放什么信息用户才能做决定？用户拒绝后模型应该收到什么？
- 危险信号：所有工具一视同仁；确认框只有"是 / 否"没有影响范围；拒绝后模型不知道为什么
- 期望信号：按动作的可逆性与外发性分级；确认信息包含影响范围与替代方案；拒绝原因作为工具结果回给模型；有审计日志

### 多服务商与结构化输出契约
- 阶梯：为什么换一个服务商结构化输出就坏（有的按 schema 约束、有的只保证是 JSON）→ 收敛、修补、抢救三层各做什么，顺序为什么这样 → 推理型模型的思考 token 算在输出上限里会怎样，运行时怎么统一处理 → 模型在 JSON 模式下"不调工具"或"只吐空白"这类服务商差异怎么定位（逐段二分、探针）
- 好题：同一套提示词从 A 模型迁到 B 模型后，JSON 解析失败率从 1% 涨到 15%，且工具一次都不调了。你会怀疑哪些差异？怎么用最少的调用定位？修在提示词层还是运行时层？
- 危险信号：只会"加一句请输出 JSON"；不知道 schema 是否随请求下发；把服务商差异修在每个 agent 里而不是运行时
- 期望信号：能说出按 JSON Schema 收敛类型 → 带校验错误让模型改一次 → 抢救的顺序；输出上限加推理余量；用探针脚本隔离变量；修在统一的调用入口

### 用 coding agent 工作的体感（可选）
- 阶梯：Claude Code / Codex / Cursor 在什么任务上可靠、什么任务上翻车 → 你怎么给它上下文（CLAUDE.md、技能、任务拆分）→ 它改错了你怎么发现（测试、diff 审查、轨迹回看）→ "代码是给 AI 和人一起维护的"对你写法的具体影响
- 好题：说一次 coding agent 把你带偏的经历：它错在哪一步、你怎么发现的、之后你在工作流里改了什么让这类错误更早暴露？
- 危险信号：只有"很好用"或"不靠谱"的笼统评价；没有具体的失败案例；不做审查全盘接受
- 期望信号：有具体的翻车案例与归因；有自己的上下文与任务拆分方法；用测试或评测把它的输出关进笼子；能说出为了让 agent 好维护而改的代码习惯

## 好题 / 坏题对比

- 坏：介绍一下 Agent 的架构。
- 好：你的 agent 偶发跑到第 30 步还没停，日志只有最终结果。要让下次能回到第 17 步看当时模型看到了什么，你会改哪些东西？续跑是怎么实现的？

- 坏：LangGraph 和 AutoGen 有什么区别？
- 好：给对话 agent 加一个实时评论员：它的上下文里放什么不放什么、预算怎么定、它的意见为什么不能直接改主 agent 的下一句？

- 坏：什么是 prompt caching？
- 好：每回合都把全部历史与检索结果拼进系统提示，缓存命中率不到 20%。你怎么重排上下文？怎么证明命中率上去了而效果没掉？

- 坏：Agent 评测怎么做？
- 好：新提示词成功率从 85% 到 87%，这 2 个点可信吗？还看哪些轨迹指标？发现一类新失败之后它会去到你流程的哪几个地方？

## 项目结合钩子

- 简历出现 Agent 循环 / harness / 运行时 → 追状态存在哪、预算超了发生什么、能不能从某一步续跑、一次最长跑了多少步
- 简历出现工具调用 / MCP → 追工具怎么分级、敏感操作怎么确认、误调过什么工具、错误怎么回给模型
- 简历出现多 agent / 子 agent → 追为什么要拆、子 agent 的上下文与预算、协作失败时怎么定位
- 简历出现 tracing / 可观测 / debugging 工具 → 追记了哪些事件、能不能按步回放、定位过什么具体故障、p95 延迟与每回合 token
- 简历出现 eval pipeline / 回归检测 / A/B → 追评测集来源、噪声底线、轨迹级指标、一次靠它拦下的坏改动
- 简历出现缓存命中率 / 成本优化 → 追上下文布局、前缀怎么保持稳定、改前改后的命中率与延迟
- 简历出现记忆 / 技能 / 渐进式披露 → 追记忆谁写谁读、有没有版本、技能什么时候加载、"给了工具模型不用"遇到过没有
- 简历出现 Claude Code / Codex / Cursor 重度使用 → 追一次翻车经历、怎么发现、工作流改了什么
- 简历出现"成功率提升 X%" → 追指标定义、样本数、跑了几次、噪声多大、有没有对照

## 出题原则

- 考"什么归代码什么归模型"的判断与理由，不考框架 API；候选人提到任何框架，追它替你做了什么、你自己写了什么。
- 每道题都要有"怎么验证"和"坏了怎么查"：候选人说了任何机制，立刻追它的轨迹指标、失败案例与回归用例。
- 简历上的 agent 项目必须深挖到一次真实故障与修法；只有 demo 叙事、没有预算与终止条件的标记为危险信号。
- 结合规模出题：日均几百次调用的项目不问集群与多租户，日均百万次的必须追成本账、缓存与降级。
- 岗位 JD 强调 coding agent 体感的，至少一道题问他自己用 agent 翻车的经历。