如何准备头部 Agent / Harness 团队：从作品集到实验能力

行业信号

Vlad Feinberg 在 frontier lab 求职建议里，把机会分成两层：LLM stack 下层的 kernel work，以及 LLM 抽象之上的 agentic loops。后者的关键，是围绕 LLM agent 做严谨、可控的工程实验。

DeepSeek Harness 的招聘给了另一侧证据。Tianyi Cui 给出的公式是 Model + Harness = Agent。模型给出能力上限，Harness 负责把能力接到上下文、工具、任务、评测、用户反馈和训练信号里。

两条线合在一起，结论很实际：头部 Agent / Harness 团队需要的作品，要能把一次 Agent 运行拆成可观察、可比较、可复现的实验。

Demo 说服力有限

普通 Agent demo 通常有三个短板：

1. 任务太少，只证明某次演示成功。
2. 没有 baseline，无法知道改动是否真的带来提升。
3. 没有 trace，失败后只能猜模型、prompt、工具、上下文哪一层出了问题。

一个小而严谨的实验，更有说服力。比如同一组任务，分别用基础 prompt、工具白名单、typed error、reviewer subagent、不同 compaction 策略跑一遍。最后给出成功率、成本、延迟、失败类型和几条关键 trace。项目可以朴素，关键是能说明你理解 Harness 变量。

作品集应该像实验报告

一个适合 Agent / Harness 岗位的项目，至少要能回答六个问题：

这和 Anthropic 对 Agent eval 的看法一致：Agent 评测通常要看 transcript 和 outcome，并组合 code-based、model-based、human graders。只看最终回答，会漏掉工具选择、重试、状态污染、绕过规则这些过程问题。

选题要窄

好的作品集不需要“大而全”。最适合的方向，是在一个真实 Agent runtime 上选一个变量做深。

Context 实验

比较 full transcript、rolling summary、retrieved memory、branch summary 对长任务成功率的影响。这里可以参考 Memory Systems，以及 Claude Code 的 Context。

Tool 实验

比较粗粒度工具和细粒度工具、free-form error 和 typed error、长 observation 和压缩 observation。Anthropic 的 tool 文章说得很清楚：工具返回结构本身会影响 eval 表现。这部分可以接着看 Tools & Actions、MCP & Skills，也可以观察 OpenClaw 的 Tools。

Trace / Eval 实验

给一组任务建立 trace schema：message、tool_call、tool_result、state_change、diagnostic、final_outcome。然后用 code grader、LLM judge、人工检查组合评分。可以参考 Evaluation 和 Claude Code 的 Debugging。

Multi-Agent 实验

比较 single agent、planner-executor、planner-executor-reviewer、parallel subagents。重点是解释 multi-agent 何时提升成功率，何时增加成本和协调失败。延伸阅读可以看 Multi-Agent Systems、Claude Code 的 Subagents、OpenClaw 的 Multi-Agent Routing。

Production / Safety 实验

研究权限、hook、human checkpoint、rollback、cost cap 怎样影响输出质量、成本和越权风险。可以和 Production、Agent Security，以及 OpenClaw 的 Security 放在一起看。

一个具体项目模板

项目可以很小：

agentic-debug-harness

问题：

代码 Agent 修复 failing tests 时，什么时候会过度修改无关文件？

任务集：

20 个小型 bugfix tasks。每个任务包含初始 repo、失败测试、预期行为、允许修改范围。

Baseline：

• naive prompt
• prompt + file whitelist
• prompt + permission hook
• prompt + reviewer subagent
• prompt + trace replay

指标：

• test pass rate
• unrelated file edits
• token / cost
• wall-clock latency
• human intervention count
• failure taxonomy

交付：

• tasks.jsonl
• run-eval.ts
• traces/*.jsonl
• results.csv
• 5 个失败 case 的短分析
• README 说明怎么复现

这个项目有价值，因为它把 Harness 设计和结果差异连起来了。

作品集里最稀缺的是归因能力

头部团队会关心你能不能区分这些失败来源：

• 模型没有理解任务。
• 工具 schema 让模型误用。
• observation 太长或太散。
• context 里丢了关键状态。
• memory 写入了错误事实。
• subagent handoff 损失了约束。
• permission policy 过松或过紧。
• eval 只测到了表面成功。

这类判断力很难靠简历写出来。最好的证明方式，是把失败 trace 摆出来，再给出一个小改动和对比结果。

90 天准备路线

第 1-2 周：复现

复现一个现有 Agent 任务：coding task、tool-use task、research task 都可以。先把 task、runner、trace、结果表跑通。

第 3-5 周：只改一个变量

选择 context、tool schema、hook、memory、subagent 中的一个变量。把 prompt、模型和工具一起改，会让实验失去解释力。

第 6-8 周：补 trace 和 eval

把每次运行记录成 episode。至少包含 tool call、tool result、stop reason、final outcome。建立成功率、成本、失败类型三类指标。

第 9-12 周：写报告

报告按实验报告写：问题、baseline、intervention、task set、metrics、trace examples、conclusion。

结论

会用 Agent 只是起点。想进入 Agent / Harness 团队，还要能把一次运行拆开看：变量怎么控，过程怎么记，结果怎么比，失败怎么归因。

一个严谨的小实验，比十个漂亮 demo 更像入场券。