研究了半年 Agent，我终于搞懂了为什么大部分团队都在做无用功
直接说结论：这半年研究的主要内容，被整理成了一套覆盖 7 个模块的免费教程，从范式转变到生产上线，中间还嵌了一个贯穿全流程的端到端实战案例。地址在文末。
但比起急着丢链接，我更想聊聊为什么花时间做这件事，以及这个过程里认知上发生的几次彻底翻转。工具到处都是，但思维方式转变才是真正值钱的东西。
一个让我清醒过来的场景
去年年底，我给一个内部项目搭了 Coding Agent。
跑 Demo 的时候效果惊艳得不行——丢一段需求描述进去，Agent 能自己读代码、写实现、跑测试、提 PR。整个过程行云流水，一度让我觉得这玩意儿要无敌了。
结果上线两周后，Agent 开始犯蠢。
它不是变笨了。是它自己写出来的代码慢慢污染了自己的运行环境——复制了一处不符合规范的实现，然后在后续任务里又复制了三处。架构漂移的速度，比你修补的速度快得多。我花了一整周手把手修 Bug，修完一个冒出两个。
那一刻才真正明白：问题根本不在 Prompt 上。
你把 Prompt 写得再好，Agent 的运行环境是一团乱麻，它照样犯蠢。就像你给一个实习生写了一百条规则，但把他扔进一个没有文档、没有规范、没有 CI 的项目里——规则再多也没用。
这就是后来花半年时间系统研究 Agent 工程的原因。
半年研究，100 篇笔记，我看到了什么
读了大量团队的工程复盘：OpenAI 的 Codex 团队、Anthropic 的多 Agent 研究系统、LangChain 的上下文工程系列、Menlo 的生产实践……
这些团队之间有一个惊人的共识：Agent 的瓶颈不在模型，在环境。
但“环境”这个词太抽象。花了很长时间才把它拆解成几个具体的问题。
第一层：Agent 看不见
OpenAI 的 Codex 团队发现，早期的 Coding Agent 写完代码就停了——它不会自己去验证。不是不想，是它看不见系统状态。没有接入浏览器，没有日志查询，没有监控。
他们后来做了什么？把 Chrome DevTools Protocol 接入 Agent 运行时。Agent 能自己打开应用、截图、看 DOM、查日志。这个改动之后，单次任务能自主工作超过 6 小时。
读到这段的时候，突然理解了一件事：我们一直在调 Prompt，但真正的杠杆在 Prompt 之外。 Agent 需要的不是更聪明的指令，而是能感知环境的基础设施。
第二层：知识放错了地方
曾经试过把所有项目规则塞进一个超长的 agents.md——以为这样 Agent 就什么都知道了。
结果完全反直觉：指令越多，Agent 表现越差。原因很简单——上下文是有限的。你塞了 5000 行规则进去，留给任务本身的思考空间就被挤掉了。而且所有东西都被标记为“重要”，等于什么都不重要。
正确的做法是“给 Agent 一张地图，而不是一本一千页的说明书”——这是 OpenAI 的原话。一个小的 agents.md 当目录，详细知识拆到结构化的子目录里，Agent 按需读取。
更残酷的是：不在仓库里的东西，对 Agent 就不存在。 Slack 讨论、Google Docs、同事脑子里的经验——全都是黑洞。你必须把隐性知识显性化写到文件里，Agent 才能用。
第三层：拆分的幻觉
这部分是踩过最深的坑。
看了很多文章说“多 Agent 是趋势”，于是也搞了一套：一个 Agent 负责规划，一个负责写代码，一个负责测试，一个负责审查。看起来很专业。
结果 Anthropic 的工程博客直接把人打醒了：按人类组织结构拆分 Agent，是最低效的方式。 写测试的 Agent 不知道实现 Agent 为什么这么写，做审查的 Agent 不了解前面排除过什么方案。它们之间反复解释背景消耗的 Token，甚至超过了真正干活的 Token。
多 Agent 的正确拆分方式是以上下文为中心——只有当两个任务的上下文可以真正隔离时，拆分才有意义。否则你就是在造一个分布式单体。
我把这些整理成了一套完整的学习路径
消化完 100 多篇笔记之后，做了一件看起来很蠢的事：把所有知识按照工程师搭建 Agent 系统时的真实认知顺序重新组织了一遍。
不是按论文结构，不是按技术栈分类，是按你实际干活时会遇到的问题来排的：
第一个模块回答“为什么”——为什么 Agent 时代需要新的工程范式。
中间的模块回答“怎么想”——上下文怎么管、架构怎么选、能力怎么封装。
最后两个模块回答“怎么干”——怎么评估质量、怎么上线运营。
还做了一个贯穿所有模块的端到端案例：自动化竞品分析 Agent 系统。从仓库怎么组织、上下文怎么管理、用哪种 Workflow 模式、到怎么评估报告质量、怎么灰度上线——每一步都给出了具体的工程决策。
写给那些还在犹豫的人
知道很多人看到“Agent”“上下文工程”“多 Agent 架构”这些词就头大。觉得这是大厂高级工程师才玩的东西，跟自己没关系。
但你想想：三年前大家看到“Kubernetes”“Service Mesh”也是这个反应。现在呢？不会 K8s 的后端工程师已经越来越难找工作了。
Agent 也是一样的趋势。只不过现在还处于早期红利期——大部分人还在用 ChatGPT 聊天，少数人已经开始搭系统了。等所有人都会用的时候，你的优势就没了。
学习这件事没有捷径，但有方向。建议是这样的：
- 先跑起来。 用 Cursor 或 Claude Code 做一个小项目，感受 Agent 怎么干活。别纠结理论，先动手。
- 踩坑就是学习。 Agent 会犯蠢，你会生气，然后你会想“它为什么会这样”——这个思考过程就是理解 Agent 的过程。
- 犯错成本极低。 Agent 时代最大的变化是：你让 Agent 改代码，它几秒钟就改好了。大胆试，快速迭代。不要怕搞坏什么。
学会用 Agent 的工程师不会被 Agent 取代。真正危险的是那些拒绝学习的人。
教程地址
hermes-engineering.dev
GitHub 开源。
写于 2026-03-23，整理自半年的研究笔记
