Agent Harness 研发工程师准备手册

这个岗位的核心不是“会调用大模型 API”,而是要证明你能把模型变成一个稳定、可控、可观测、可评测、可交付的 Agent 系统。

适合有后端、平台工程、核心系统、测试开发、全栈工程背景的人转向大模型应用基础设施方向。

Agent Runtime Tool Calling MCP Context Engineering Sandbox Eval Trace

1. 岗位本质

Agent Harness 研发工程师做的是模型之外的工程系统。模型负责推理和生成,Harness 负责让模型能安全、稳定地调用工具、执行任务、观察反馈、恢复失败、完成交付。

可以把这个岗位理解成:给大模型造“操作系统”和“执行环境”的工程师。
用户目标 ↓ 任务拆解 / Planning ↓ 选择工具 / Tool Use / MCP ↓ 执行动作 / Sandbox / API ↓ 观察结果 / Observation ↓ 失败重试 / 修正 / 继续执行 ↓ 验证完成 / Eval / Trace ↓ 输出最终结果

和普通后端的区别

维度 普通后端 Agent Harness
执行模式 请求 → 服务 → 数据库 → 返回 目标 → 推理 → 工具调用 → 环境反馈 → 再推理 → 验证
确定性 业务逻辑相对确定 模型输出半确定,需要约束、验证、回放
核心风险 接口错误、性能、数据一致性 幻觉、循环、误调用工具、越权、上下文污染
质量证明 单测、集成测试、监控 Trace、离线 Eval、任务成功率、工具调用准确率、成本和失败模式

2. 知识地图

工程底座

  • 后端服务设计
  • API 设计
  • 异步任务
  • 状态机
  • 消息队列
  • 数据库与缓存
  • 日志与监控

Agent 核心

  • Agent Loop
  • Planner / Executor
  • Tool Registry
  • MCP
  • Memory
  • Context Builder
  • Checkpoint

生产化能力

  • Sandbox
  • 权限分级
  • Guardrails
  • Trace 回放
  • Eval 流水线
  • 成本控制
  • 人类确认机制
准备重点:不要把自己包装成“算法研究员”,而要包装成“能把不稳定的智能能力工程化的人”。

3. LLM 基础知识

不一定要会训练大模型,但必须理解模型调用、上下文、工具调用和幻觉边界。

必须掌握的关键词

Token Context Window Embedding RAG Function Calling Structured Output Streaming Temperature Top-p KV Cache Prompt Injection Hallucination

面试官可能怎么问

  • 为什么上下文越长不一定越好?
  • RAG 召回错了怎么办?
  • 工具调用结果太长怎么处理?
  • 模型连续调用 20 步后开始跑偏怎么办?
  • 如何降低 token 成本?
  • 什么时候用大模型,什么时候用小模型?
答题要点:不要只说“优化 Prompt”。要从上下文选择、结果校验、工具约束、模型路由、成本控制和失败恢复几个角度回答。

4. Agent Runtime / Agent Loop

这是 Agent Harness 岗位最核心的能力。你要能手写或讲清楚一个最小可用 Agent Runtime。

Agent Runtime 关键模块: 1. Model Adapter:屏蔽不同模型 API 差异 2. Context Builder:构造 system prompt、历史、记忆、工具描述 3. Planner:任务拆解和下一步决策 4. Tool Registry:工具注册、Schema、权限和执行 5. Executor:执行工具,处理 timeout / retry / error 6. State Store:保存任务状态、步骤、checkpoint 7. Observation Handler:把工具结果转成模型可理解的反馈 8. Stop Condition:判断完成、失败、超预算或需要人工介入 9. Trace Recorder:记录完整执行链路 10. Eval System:离线回放与评分

简化伪代码

while not task.finished:
    context = context_builder.build(task, memory, available_tools)
    model_output = model.generate(context)

    if model_output.is_final_answer():
        task.finish(model_output.answer)
        break

    tool_call = parse_tool_call(model_output)
    permission.check(tool_call)

    result = tool_executor.execute(tool_call)
    trace.record(model_output, tool_call, result)

    task.update_state(result)

    if stop_policy.should_stop(task):
        task.stop_with_reason()

面试高频问题

  • 如果 Agent 一直循环怎么办?
  • 如果模型错误调用工具怎么办?
  • 如果任务做到一半失败了,怎么恢复?
  • 如何判断 Agent 真的完成了任务?
  • 如何设计一个可插拔的 Tool 系统?
  • 如何让 Agent 支持暂停、继续、回滚?

5. 工具调用与 MCP

Agent 不能只会聊天,它要能使用工具。工具系统不是简单写几个函数,而是一个需要 Schema、权限、审计、重试和隔离的工程体系。

Tool Registry 设计

字段 作用
Tool Name工具名称,模型调用时使用。
Description给模型看的工具说明,影响模型是否正确选择工具。
Input Schema参数结构,建议 JSON Schema。
Output Schema返回结构,便于模型理解和系统校验。
Permission Level权限等级,决定是否允许自动执行。
Timeout防止工具长时间卡住。
Retry Policy失败重试策略。
Idempotent是否幂等,影响是否允许自动重试。
Audit Log记录谁、何时、为什么调用。
Requires Confirmation危险操作是否需要人工确认。

Java 风格接口示例

public interface AgentTool {
    String name();
    String description();
    JsonSchema inputSchema();
    ToolResult execute(ToolContext context, JsonNode input);
    PermissionLevel permissionLevel();
    boolean requiresConfirmation();
    Duration timeout();
}

MCP 要理解什么

  • MCP 解决的是“让外部能力标准化暴露给 Agent”。
  • 它可以让 Agent 访问文件、数据库、浏览器、Git、内部系统等工具。
  • 面试不一定要求手写 MCP Server,但要知道它和 Tool Calling 的关系。

6. Context Engineering / Memory / RAG

Agent 能不能做长任务,关键不只是模型能力,而是上下文管理能力。

上下文来源

  • 用户当前输入
  • 系统指令
  • 历史对话
  • 工具描述
  • 工具返回结果
  • 代码 / 文档 / 数据库检索结果
  • 长期记忆和任务状态

核心策略

  • 上下文分层
  • 历史摘要
  • 工具输出裁剪
  • 重要信息保留
  • 无关信息丢弃
  • RAG 召回校验
  • 上下文污染隔离

面试高频问题

  • Agent 做一个 2 小时任务,上下文爆了怎么办?
  • 用户给了 100 个文件,怎么让 Agent 找到相关文件?
  • 如何避免历史对话污染当前任务?
  • 记忆写入有什么风险?
  • RAG 检索结果互相矛盾怎么办?
答题原则:上下文不是越多越好,而是要做选择、压缩、分层、验证和隔离。

7. 沙箱、权限和安全

Agent 一旦能执行命令、调用 API、读写文件、访问数据库,就必须有严格的安全边界。

权限分级示例

等级 能力 控制策略
L0 只读模型推理 自动执行
L1 读文件、查资料、读取元数据 工作区内自动执行
L2 写临时文件、执行测试、生成报告 沙箱中执行,记录 Trace
L3 修改项目代码、调用内部 API 权限校验,必要时人工确认
L4 操作生产数据、发邮件、删除资源、付款 默认禁止或强制审批

必须掌握的安全点

  • Sandbox:命令和代码在隔离环境里执行。
  • 命令白名单 / 黑名单:阻止危险命令。
  • 网络隔离:限制外部访问域名和端口。
  • Secret 脱敏:避免模型读到密钥、Token、证书。
  • Prompt Injection 防护:外部内容只作为数据,不作为指令。
  • 人工确认:高风险操作必须确认。
  • 审计日志:所有工具调用可追溯。
  • Checkpoint / Rollback:支持回滚错误操作。
高频场景:用户让 Agent 执行 rm -rf /;Agent 读到了 .env;工具返回内容里包含“忽略之前所有指令”;Agent 要操作生产数据库。面试时要能分别说清楚拦截策略。

8. Eval / 评测 / 观测体系

很多人会做 Agent Demo,但不会证明 Agent 真的变好了。Agent Harness 研发岗位非常看重评测和观测。

Eval Harness 设计

测试任务集 ↓ 初始化环境 ↓ Agent 执行任务 ↓ 记录完整 Trace ↓ 自动评分:代码型评分 / LLM Judge / 人工评分 ↓ 生成指标:成功率、成本、耗时、失败原因 ↓ 回归对比:模型版本、Prompt、工具描述、上下文策略

核心指标

质量指标

  • 任务成功率
  • 工具调用成功率
  • 幻觉率
  • 测试通过率
  • 用户接管率
  • 回滚率

效率指标

  • 平均执行步数
  • 平均 token 成本
  • 平均耗时
  • 重试次数
  • 失败恢复率
  • 单位任务成本

面试标准回答模板

我会建设一个离线 Eval Harness。
每个 case 包含任务描述、初始环境、可用工具、预算、预期结果和评分器。
执行时记录完整 trace,包括模型输入输出、工具调用、工具结果、错误和重试。
评分器分为代码型、模型型和人工型。
每次修改 prompt、工具描述、模型版本或上下文策略后,都跑 regression eval,比较成功率、成本、耗时和失败模式。

9. 建议准备一个作品项目

这个岗位光靠说很难赢,最好有一个可以展示的项目。建议做一个:企业代码库 Agent Harness Demo

项目目标

  • 读取一个 Java / Spring Boot 项目。
  • 理解用户需求。
  • 定位相关文件。
  • 修改代码。
  • 运行测试。
  • 根据错误自动修复。
  • 输出执行报告。

最小架构

层次 建议技术 作用
前端Vue / React展示任务、步骤、Trace、人工确认。
后端Spring Boot / Python / GoAgent Runtime、工具注册、任务管理。
模型层OpenAI-compatible API / Claude / DeepSeek支持多模型适配和路由。
工具层文件读取、代码搜索、Shell、Git Diff、测试执行让 Agent 可以操作项目。
沙箱层Docker隔离执行命令和代码。
存储层PostgreSQL / MySQL保存任务、状态、Trace。
评测层自定义 Eval Runner跑任务成功率、成本和失败分析。

展示亮点

  • Agent Loop 不是黑盒,有自己的状态机。
  • 每一步都有 trace。
  • 工具有权限分级。
  • Shell 在沙箱里执行。
  • 支持失败重试。
  • 支持上下文压缩。
  • 支持离线评测。
  • 支持不同模型对比。
  • 支持人工确认危险操作。

10. 高频面试题与回答方向

问题 1:Agent 和普通 Chatbot 有什么区别?

Chatbot 主要是生成回复。Agent 有目标、状态、工具、环境反馈和多轮执行能力。模型提供推理能力,Harness 提供执行能力和工程边界。

问题 2:如何设计一个 Agent Harness?

  1. Model Adapter:屏蔽不同模型 API 差异。
  2. Context Builder:构造 prompt、历史、记忆、工具描述。
  3. Tool Registry:管理工具 schema、权限、执行。
  4. Agent Runtime:控制循环、状态机、终止条件。
  5. Sandbox:隔离代码和命令执行。
  6. Memory Store:保存长期记忆和任务状态。
  7. Trace System:记录每一步。
  8. Eval System:离线回放和自动评分。
  9. Guardrails:权限、安全、敏感操作确认。

问题 3:Agent 一直循环怎么办?

设置最大步数、最大 token、最大耗时;检测重复工具调用和重复 reasoning;如果连续 N 次没有状态变化,就触发反思、换模型、请求人工介入或停止。终止条件应包括预算终止、目标完成终止、无进展终止、风险终止和人工终止。

问题 4:工具调用失败怎么办?

  • 参数错误:让模型修正参数后重试。
  • 权限错误:拒绝或请求人工确认。
  • 超时:重试、降级或中断。
  • 外部服务错误:fallback 或排队重试。
  • 模型误用工具:收敛工具描述,加入示例和校验。
  • 连续失败:停止并输出诊断报告。

问题 5:如何判断 Agent 真的完成任务?

不能只相信模型自己说完成。要用外部验证:代码任务跑测试;数据任务查校验规则;文档任务检查结构和覆盖项;操作任务检查目标状态;必要时用 LLM Judge + 人工抽检。

问题 6:如何防 Prompt Injection?

  • 用户内容、网页内容、工具返回内容都视为不可信输入。
  • 系统指令和工具权限不能被外部内容覆盖。
  • 工具调用前做权限校验。
  • 外部内容进入上下文时加边界标记。
  • 敏感操作必须经过策略引擎和人工确认。
  • 工具输出中的“忽略之前指令”等内容只作为数据,不作为指令。

11. 简历怎么写更有竞争力

不要写得太泛,比如“熟悉大模型、熟悉 LangChain、熟悉 Prompt Engineering”。要写成可验证的工程能力

推荐写法

设计并实现 Agent Runtime,支持多轮 Agent Loop、工具调用、任务状态管理、失败重试和执行 Trace。
实现 Tool Registry,支持工具 Schema 注册、权限分级、超时控制、幂等校验、人工确认和审计日志。
建设 Agent Eval 流水线,支持离线任务回放、自动评分、失败样本聚类、模型 A/B 对比和成本统计。
基于 Docker Sandbox 执行 Agent 生成代码,限制文件系统、网络访问和命令权限,降低执行风险。
针对长上下文任务设计 Context Builder,支持历史压缩、RAG 召回、工具结果裁剪和关键信息保留。

你的背景可以主打的优势

  • 做过复杂后端系统,有生产级工程意识。
  • 做过接口治理,天然适合 Tool / MCP / API Contract 设计。
  • 做过消息队列、缓存、权限、日志,适合 Agent Runtime。
  • 做过金融 / 核心系统,更懂审计、权限和风险控制。
  • 有团队管理和项目落地经验,能把 Agent 从 demo 推到生产。

12. 30 天准备计划

时间 目标 交付物
第 1 周 不用框架,自己写一个最小 Agent Runtime。 模型调用、工具调用、多轮循环、终止条件、Trace 记录。
第 2 周 做 Tool + Sandbox + 权限。 文件读取工具、代码搜索工具、Shell 执行工具、Docker 沙箱、权限分级、危险操作拦截。
第 3 周 做 Eval。 20~50 个测试任务、离线回放、代码型评分器、LLM Judge、Trace 页面、成功率 / 成本 / 耗时统计。
第 4 周 包装项目和准备面试表达。 架构图、核心代码、完整执行 Trace、失败案例分析、优化前后指标对比、安全设计、成本控制方案。

每日学习节奏建议

  • 每天 30 分钟:读 Agent / Tool / MCP / Eval 相关材料。
  • 每天 60~90 分钟:写代码实现自己的 Harness。
  • 每天 20 分钟:记录一次失败案例和优化思路。
  • 每周末:整理一次架构图和面试表达。

13. 面试定位

你可以把自己定位为:

我不是模型训练背景,但我擅长把不稳定的智能能力工程化。我关注的是 Agent Runtime、工具调用、上下文管理、权限控制、执行 Trace、评测回放和生产稳定性。我的优势是后端平台和复杂系统落地,可以把 Agent 从 demo 做成可观测、可评测、可控制的生产系统。

最终复习清单

  • 能讲清楚 Agent 与 Chatbot 的区别。
  • 能画出 Agent Harness 架构图。
  • 能解释 Agent Loop 的每一步。
  • 能设计 Tool Registry。
  • 能说明 MCP 解决什么问题。
  • 能设计上下文压缩策略。
  • 能回答 Agent 循环、失败、误调用工具时怎么办。
  • 能设计 Sandbox 和权限分级。
  • 能设计离线 Eval 和 Trace 回放。
  • 能展示一个小型 Agent Harness Demo。

14. 参考资料

以下资料适合继续深入学习。打开本文档时可点击链接访问。