Agent Harness 手册

外观

作品集项目：三个能写进简历的 Agent 项目 ​

能力对标一页的结论是：Agent 工程岗要的是"能把 agent 从 demo 推进到生产、并能证明它真的变好了的人"。问题来了——如果你现在没有这样的在职经历，拿什么证明？

答案是作品集项目。但不是随便一个"用 LangChain 搭的聊天机器人"，而是照着 JD 词频反向设计的项目：每个项目都要能挂上若干条 JD 高频要求，每条都能在面试里经得住"怎么做的、为什么这么做、出过什么事故"的追问三连环。

数据口径

本页所有 JD 引用来自 2026-08-11 ~ 08-12 对 44 份真实在招 JD 的调研（国内 27 岗、国外 17 岗，人工核对的词频粗统计），完整清单与出处见 JD 全景。引文均标注公司与岗位名，未抓到原文的一律不引。

选项目的原则：让词频替你出题 ​

先看一下雇主在为什么付钱。国内 27 岗的词频头部是：Agent 运行时/Harness（15 岗）、工具调用（13 岗）、评测（12 岗）、上下文工程（10 岗）；往下是多智能体（9 岗）、可观测（7 岗）、MCP（5 岗）、记忆与沙盒（各 4 岗）。国外 17 岗的头部同样是 evals（10 岗）。

三个项目就是照着这张词频表设计的：

text
                三个项目 × JD 词频覆盖图
┌──────────────┬─────────────────────────────────────┐
│ 项目一        │ Agent Loop ● 工具 ● 上下文 ● 评测     │
│ mini harness │ （词频前四名，一次全覆盖）              │
│  + evals     │                                     │
├──────────────┼─────────────────────────────────────┤
│ 项目二        │ 工具/MCP ● 权限安全 ● 工程基本功       │
│ 生产级        │ （MCP 5 岗、沙盒/权限多点名，          │
│ MCP server   │  后端能力是所有 JD 的隐性硬门槛）       │
├──────────────┼─────────────────────────────────────┤
│ 项目三        │ 多智能体 ● 记忆 ● 可观测              │
│ multi-agent  │ （9/4/7 岗，架构类岗位的区分度项）      │
│ /长时程 agent │                                     │
└──────────────┴─────────────────────────────────────┘

先立一条军规

作品集和玩具的区别只有一个：有没有被认真评测过、有没有处理过真实失败。 腾讯混元的 JD 要求"对 agentic coding 的能力边界和 failure mode 有切身体感"——体感伪造不出来。下面每个项目的验收标准里都包含"制造故障并记录失败模式"，这不是可选项，是项目的灵魂。只跑通 happy path 的项目，写进简历就是把面试引向你的知识盲区。

项目一：带评测体系的 mini harness ​

解决什么真实问题。 Agent demo 遍地都是，但"改了一行 system prompt，agent 到底是变好了还是变坏了"没人答得上来。这个项目把渐进式教程里的 v1–v3（agent loop → 工具系统 → 规划与压缩）作为底座，再按从零搭一套 Agent 评测给它配一套三层评测：你自己的 harness 每次改动都有分数佐证。

覆盖哪些 JD 高频要求。 一个项目打中词频表前四名：

  • Agent Loop / Harness（15 岗）：美团「Agent Harness 工程师」要求"参与 System Prompt、Tools、Skills、上下文管理、Agent Loop、任务状态及异常恢复等核心能力建设"；
  • 工具调用（13 岗）：月之暗面「Agentic Growth Engineer」要求"能围绕 Agent 构建高质量的 scaffolding：context 如何组织、工具如何抽象、循环如何终止、失败如何恢复、效果如何评估"——这句话几乎就是这个项目的验收清单；
  • 评测（国内 12 岗 / 国外 10 岗）：字节「Agent Harness工程师-AI数据与安全」要求"落地自动化 EVAL 流水线、版本回归、A/B 实验能力"；Cognition 写得更透——"Build evals that actually capture what matters... making sure the numbers mean something"；
  • 上下文工程（10 岗）：截断与会话压缩就是最小的上下文工程实践。

技术要点。 工具注册表与错误回灌格式；按不可逆性分级的审批闸口；事件驱动的上下文压缩；单元级/轨迹级/结果级三层断言；每个 case 跑 N 次报通过率；bad case 回流进评测集的机制；接 CI 做回归门禁。

两档投入。

档位内容投入估算
低配版跑通 v1–v3，接真实模型，写 20 条真实 case + 三层断言的评测脚本约 1 周
完整版低配版 + CI 回归门禁 + 多模型/多 prompt 矩阵对比 + 一份"我改过什么、分数怎么变"的实验报告约 2 周

验收标准。 评测集 ≥20 条且含已知成功与已知失败；判定器先用 MockLLM 校准过；能演示"改一处 prompt → 评测分数变化"的完整闭环；README 里记录至少 3 个你亲手制造的故障（工具报错死循环、上下文灌爆、计划漂移）及修复前后的轨迹对比。

简历上怎么写（STAR）。

"为自研 mini agent harness 搭建三层评测体系：20 条真实 case 的评测集、单元/轨迹/结果三层断言与多次采样通过率统计（S/T）；实现工具错误分类回灌、上下文事件驱动压缩与 CI 回归门禁（A）；prompt 迭代从'凭感觉'变为每次变更可量化回归，定位出 3 类此前未察觉的失败模式（R）。"

项目二：生产级 MCP server ​

解决什么真实问题。 Agent 的能力上限经常被工具供给侧卡住：模型想查的数据不在它手里。MCP（Model Context Protocol）是当下工具接入的事实标准，但网上能找到的 MCP demo 几乎都是"hello world 级"——包一个公开 API，没有错误处理，没有权限概念。做一个接真实数据源、敢给别人用的 MCP server，正好补上这个空档。

覆盖哪些 JD 高频要求。

  • MCP（国内 5 岗点名，且出现在高级岗位）：月之暗面「资深Agent研发工程师」要求"熟悉 Agent 主流技术栈（如 Skills、MCP、Sandbox 等），有真实 Agent 系统的开发经验"；小红书「Agent Harness 工程师」要求"对 LLM Agent、Tool Calling、MCP、Agent Runtime、Coding Agent、Multi-Agent 等方向有深入兴趣或实践经验"；国外 Anthropic 的 Applied AI 岗把 MCP 写进 production LLM 经验清单；
  • 工具/安全交叉项：小红书同一岗位要求"建设 Agent 身份认证与权限治理能力，解决权限穿透、最小授权和安全边界问题"；阿里实习岗已要求"具备大模型幻觉、Prompt 注入等风险的工程化应对思路"——MCP server 正是这些要求的实体载体；
  • 隐性项：工程基本功。一个生产级服务涉及的重试、限流、缓存、日志、部署，是所有 JD 硬性要求栏里的后端能力。

技术要点。 选一个你真用的数据源（自己的笔记库、某个内部 API、一个公开数据集）；工具划分粒度与描述写法（描述是写给模型看的 prompt）；结构化错误返回而非抛异常；只读/写操作分级与鉴权；超时、限流、幂等；接进 Claude Code 或任意 MCP 客户端实测。

两档投入。

档位内容投入估算
低配版单数据源、3–5 个只读工具、结构化错误、接入一个 MCP 客户端跑通约 1 周
完整版低配版 + 写操作的权限分级与审计日志 + 限流/缓存/重试 + 一组"恶意输入"测试（注入式参数、越权请求）+ 部署上线约 2 周

验收标准。 能被真实 MCP 客户端调用完成一个端到端任务；错误路径全部返回模型可读的结构化信息（不吐 stack trace）；写操作有权限闸口与审计记录；README 含威胁模型一节：这个 server 把什么暴露给了模型，边界画在哪。

简历上怎么写（STAR）。

"为 XX 数据源设计并实现生产级 MCP server，支撑 agent 直接查询/操作 XX（S/T）；设计工具粒度与描述、结构化错误回灌、只读/写操作权限分级与审计日志，并以注入式参数与越权请求做对抗测试（A）；server 被 XX 个 agent 工作流日常使用，工具调用错误率从初版的 XX% 降到 XX%（R）。"

数字自己填真实的——没有真实用户就写"支撑我自己的 N 个日常 agent 工作流"，诚实比漂亮重要。

项目三：多智能体协作 demo 或长时程任务 agent ​

解决什么真实问题。 单 agent 在长任务上必然撞上两面墙：上下文装不下、目标会漂移。这个项目二选一：多智能体协作 demo（一个 orchestrator 把任务分派给多个专职子 agent，处理结果合并与冲突），或长时程任务 agent（一个需要跑几十上百步的任务，如"监控某信息源并每日产出摘要报告"，靠持久记忆与断点续跑撑住）。

覆盖哪些 JD 高频要求。

  • 多智能体（9 岗）：月之暗面「Agent产品工程师（multi-agent 方向）」的表述最有指导性——"设计 Agent 与 Agent 之间协作的交互协议，把协作本身视作一种新型 harness"，且硬性要求里写明"可以快速自己手搓一套 Harness 来验证 Agent 协作与编排效率"；百度「智能体算法工程师」要求"长短期记忆管理、多智能体协同"；腾讯元宝岗列了"多 Agent 协作模式、Human-in-the-loop"；
  • 可观测（7 岗）：字节 Harness 岗要求"搭建 Agent 全链路可观测体系：执行轨迹追踪、结构化日志采集、性能监控、异常告警、可视化调试、链路回放"；小红书要求"覆盖 Trace/Log/Metric/Event 全链路，支持调试回放和故障诊断"——多 agent 系统没有 trace 等于黑盒，这一项是刚需不是加分项；
  • 记忆（4 岗）：长时程方向的核心，对应记忆系统的持久化与外置设计。

技术要点。 子 agent 的任务契约（输入什么、产出什么、超时怎么办）；orchestrator 与 worker 的上下文隔离——子 agent 只带回结论不带回过程（子 Agent的核心动机）；跨会话的状态持久化与断点续跑；全链路 trace：每个 agent 的每次调用可回放、可归因。

两档投入。

档位内容投入估算
低配版1 个 orchestrator + 2 个专职子 agent，结构化任务契约，JSONL 轨迹日志可回放约 1.5 周
完整版低配版 + 持久记忆与断点续跑 + trace 可视化（哪怕是个简陋的本地网页）+ 一组协作失败模式的记录（任务丢失、结果冲突、循环委派）约 2–2.5 周

验收标准。 跑通一个单 agent 做不好的任务（用项目一的评测思路对比单 agent 与多 agent 的完成率，这是最有说服力的数据）；任意一次运行能完整回放并回答"哪个 agent 在哪步走偏了"；记录至少 2 个多智能体特有的失败模式及对策。

简历上怎么写（STAR）。

"单 agent 在 XX 长任务上因上下文膨胀导致完成率仅 XX%（S）；我设计 orchestrator + 专职子 agent 架构：结构化任务契约、上下文隔离、全链路 trace 与断点续跑（T/A）；同任务完成率提升至 XX%，且任意失败可在 5 分钟内回放归因到具体 agent 的具体步骤（R）。"

三个项目的取舍 ​

项目一 mini harness + evals项目二 MCP server项目三 multi-agent / 长时程
主要覆盖词频前四名（loop/工具/上下文/评测）MCP、权限安全、后端基本功多智能体、记忆、可观测
适合的画像所有人——这是必做项后端转 Agent 的工程师算法背景或冲架构岗的人
顺序建议第一个做第二个做最后做，且复用项目一的评测

如果只有两周，做项目一的完整版；有一个月，加项目二。项目三不着急——一个被认真评测过的单 agent，胜过一个没人知道是否好用的多 agent 系统，这也是本站一贯的设计立场（见设计原则与常见陷阱）。

延伸阅读 ​