研究了半年 Agent，我终于搞懂了为什么大部分团队都在做无用功
我花了半年读了 Anthropic、OpenAI、LangChain 等团队的技术博客，做了 100 多篇笔记。整理完之后，我发现大部分人（包括半年前的我）对 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 取代。真正危险的是那些拒绝学习的人。
教程地址
开源：GitHub
如果对你有帮助，Star ⭐ 一下就是最大的支持。也欢迎分享给身边在研究 Agent 的朋友。
写于 2026-03-23，整理自半年的研究笔记