今天和一个朋友聊天。他说自己做了一个非常精简的 Agent Harness，准备开源，让大家可以直接用。
我第一反应不是问他写了多少代码，而是问：
你看过 Pi Agent、OpenCode、DSH 吗？
他说，没有深入研究过。
那一刻我没有继续追问，但一个问题在我脑子里转了一下午：今天成为一个 Agent 应用工程师，真正重要的到底是什么？ 是能够自己写一个 Agent Loop，还是能够把 Agent 真正做成一个有价值、能生产、能赚钱的产品？
这篇文章把那条成长路线完整画出来。
一、第一阶段：先自己造一个 Agent，是很好的学习方式
我并不认为朋友做 Harness 是一件没意义的事情。恰恰相反。
从零实现一个 Agent，是理解 Agent 最好的方式之一。 你会真正遇到这些问题：
- Context 怎么管理？
- Tool 怎么调用？
- Agent Loop 怎么跑？
- 怎么处理错误？
- 怎么做 memory？
- 怎么做 session？
- 怎么控制权限？
- 怎么让 Agent 持续执行？
- 怎么处理长任务？
- 怎么评估 Agent 到底有没有做好？
这些东西，如果只停留在「调用一个 API + 写一个 Prompt」，很难真正理解。所以对于刚进入 Agent 开发的人：不要害怕造轮子。 自己实现一个 Agent Harness，非常适合作为第一阶段的「毕业设计」。
但问题在于：不能停在这里。
二、第二阶段：不要把「我会造 Agent」误认为「我会做 Agent 产品」
这是我想给 Agent 应用工程师的第一个重要建议：
学习阶段可以造轮子，产品阶段不要重复造轮子。
现在已经有很多成熟的 Agent Harness / Coding Agent：Pi、OpenCode、DSH、Claude Code、Codex……如果你没有深入研究这些系统，就重新实现一个类似的东西，很容易陷入一种状态：「我也实现了一个 Agent。」但这并不意味着你创造了新的价值。
因为用户真正关心的不是：你的 Agent Loop 是不是自己写的——而是 它能不能帮我把事情做好。
这就是从 Agent 工程学习 到 Agent 应用工程 的分水岭。
三、第三阶段：真正有价值的方向，是垂直 Agent
我当时给朋友的建议是：
如果你想证明自己会做 Agent，做 Harness 很好；但如果想做一个能够变现的产品，我更建议做能够生产某一类垂直 Agent 的 Agent。
这是两个完全不同的方向。通用 Agent 追求 什么都能做；垂直 Agent 追求 一件事情做到极致。所以它们的优化目标甚至是相反的：
| 通用 Agent 追求 | 垂直 Agent 追求 |
|---|---|
| 更强模型 | 更低成本 |
| 更大 Context | 更低延迟 |
| 更多工具 | 更少 Token、更少工具 |
| 更强泛化能力 | 更稳定、更高成功率 |
| 更复杂的 Planning | 更容易部署、更容易规模化 |
| 更长的执行能力 |
一句话：通用 Agent 拼能力上限，垂直 Agent 拼单位成本的生产力。
这可能是 Agent 应用工程师真正应该进入的战场。
四、第四阶段：从「写 Agent」走向「编译 Agent」
这里还有一个我觉得特别有意思的方向。
假设：OpenCode 上有一个 Agent，在某一类任务上表现非常好。它可能用了：大模型、很大的 Context、十几个 Tools、MCP、Shell、Filesystem、Git、Subagents、很复杂的 Planning。
但是，如果我要把这个 Agent 部署到一个资源非常有限的环境里呢？比如 嵌入式设备。
这时候最有价值的事情可能不是：再写一个更小的 OpenCode。而是：把这个 OpenCode 上跑得好的 Agent，「编译」成一个嵌入式 Agent。
五、Agent Compiler 可能成为一个新的工程方向
把「编译」这个过程画出来，它可以变成一条完整的管线：
通用 Agent
OpenCode / DSH / ...
│
▼
高质量执行轨迹
│
▼
Evals
│
▼
Agent Compiler
┌────┼────┐
▼ ▼ ▼
Prompt Model Runtime
优化 蒸馏 优化
│ │ │
└────┼────┘
▼
垂直 Agent
│
▼
更低成本 / 更高效率
# generated by hugo AI
它不是重新发明 Agent，而是：
把已经验证过的 Agent 能力，压缩、固化、优化成生产环境真正需要的形态。
这时候，Agent 工程师做的事情就开始从：
How to build an Agent?
变成：
How to make an Agent production-ready?
甚至进一步：
How to compile an expensive general Agent into a cheap specialized Agent?
六、Evals 是这里真正关键的东西
但有一个前提：
没有 Evals，就没有真正意义上的 Agent 工程。
因为你怎么知道编译之后真的变好了？
General Agent Vertical Agent（编译后）
成本：$1 成本：$0.03
成功率：92% → 成功率：94%
# generated by hugo AI
这才叫优化。如果只是：代码少了、Prompt 短了、Token 少了，但成功率从 92% 掉到 70%，那不是优化，是退化。
所以 Agent 应用工程师下一阶段应该掌握的不只是 Prompt + Tool + RAG，而应该开始掌握：
SPEC + Evals + Trajectory + Feedback + Optimization
最终形成：
SPEC
↓
Agent
↓
Evals
↓
Trajectory
↓
Failure Analysis
↓
Optimization
↓
New Agent
↓
Production Feedback
↓
Evals
# generated by hugo AI
到这一步，才开始像真正的 Agent Engineering。
七、一个 Agent 工程师的四级成长路线
可以把一个 Agent 工程师的成长写成四个阶段：
Level 1：Agent 使用者。 会调模型、写 Prompt、调 Tool、接 MCP、做 RAG。目标是——让 Agent 跑起来。
Level 2：Agent Builder。 开始自己实现 Agent Loop、Context、Memory、Tool、Session、Permission、Error Recovery。目标是——真正理解 Agent 为什么能工作。 这个阶段，自己做一个 Harness 非常有价值。
Level 3：Agent Application Engineer。 开始关注一个具体业务场景、用户真实需求、Task Success Rate、Evals、Cost、Latency、Reliability、Production Feedback。目标是——让 Agent 把一件事情稳定做好。
Level 4：Agent System Engineer。 开始思考：如何从通用 Agent 得到垂直 Agent？如何自动生成 Agent？如何用 Trajectory 做优化？如何做 Agent Compiler？如何蒸馏模型？如何压缩 Context？如何优化 Runtime？如何让 Agent 自我改进？目标是——让生产 Agent 的制造本身变成一个工程系统。
八、这可能是这篇文章最核心的价值观
写到最后，落在一个很简单的判断上：
不要以「我能不能写出一个 Agent」作为自己的终点。
真正的终点，是你能不能让 Agent 在真实世界里创造稳定、可衡量、可规模化的价值。
甚至可以更尖锐一点：
会写 Agent，不稀缺。
能把 Agent 做成产品，也只是第一步。
真正稀缺的是：知道什么该交给通用 Agent，什么应该被固化成垂直 Agent，并且能用 Evals 把它持续优化到极致。
这也会让这篇文章避免变成一篇普通的「Agent 技术教程」。它真正讲的是：一个 Agent 工程师应该如何从「技术兴趣」走向「产品价值」，再从「做一个 Agent」走向「制造 Agent」。
九、收尾
最后用一句话收束这条路线：
第一阶段，我们学习怎么做 Agent；第二阶段，我们学习怎么用 Agent 解决问题；第三阶段，我们开始学习怎么制造能解决问题的 Agent。
这可能才是 Agent 应用工程师真正的成长曲线。
你现在卡在哪一级？欢迎留言讨论。