研究了半年 Agent，我终于搞懂了为什么大部分团队都在做无用功
花半年读 Anthropic / OpenAI / LangChain / Menlo 等团队的技术博客、做 100+ 篇笔记后的认知翻转：Agent 的瓶颈不在模型，也不在 Prompt，而在”环境”。作者把”环境”拆成三层——Agent 看不见系统状态、知识放错了地方、多 Agent 按人类组织结构拆分是幻觉。
基本信息
- 来源类型：文章（掘金 · 作者：芋圆ai）
- 原文位置：raw/articles/2026-06-10-125558-tg-0e4f81.md
- 原文 URL：https://juejin.cn/post/7619886405088690195
- 写作时间：2026-03-23（整理自半年研究笔记）
- 消化日期：2026-06-10（2026-09-22 重新落盘）
核心观点
- 瓶颈不在 Prompt，在环境：作者给内部项目搭的 Coding Agent 跑 Demo 时”行云流水”（读代码 → 写实现 → 跑测试 → 提 PR），上线两周后开始犯蠢。原因不是模型变笨，而是它自己写出的代码污染了自己的环境——复制了一处不符合规范的实现，随后又在后续任务里复制了三处。架构漂移的速度比修补的速度还快，作者花一整周手修 Bug，“修完一个冒出两个”。由此得出的结论：你把 Prompt 写得再好，如果 Agent 的运行环境是一团乱麻，它照样犯蠢——如同给实习生写了一百条规则，却把他扔进没有文档、没有规范、没有 CI 的项目里。
- 共识：Agent 的瓶颈不在模型，在环境：作者横向读了 OpenAI Codex 团队、Anthropic 多 Agent 研究系统、LangChain 上下文工程系列、Menlo 的生产实践，发现这些团队之间有一个”惊人的共识”。“环境”这个词太抽象，作者把它拆解成三个具体层次（即本文的三层认知翻转）。
- 第一层——Agent 看不见系统状态：OpenAI Codex 团队发现早期 Coding Agent 写完代码就停，不是不想验证，而是它看不见系统状态：没有接入浏览器、没有日志查询、没有监控。他们的解法是把 Chrome DevTools Protocol 接入 Agent 运行时，让 Agent 能自己打开应用、截图、看 DOM、查日志。改动之后，单次任务能自主工作超过 6 小时。作者的领悟：“我们一直在调 Prompt，但真正的杠杆在 Prompt 之外。”
- 第二层——知识放错了地方：作者试过把所有项目规则塞进一个超长
agents.md，结果完全反直觉：指令越多，Agent 表现越差。原因是上下文有限——塞 5000 行规则进去，留给任务本身的思考空间被挤掉；而且所有东西都被标记为”重要”，等于什么都不重要。OpenAI 的原话是 “给 Agent 一张地图，而不是一本一千页的说明书”：小的 agents.md 当目录，详细知识拆到结构化子目录，Agent 按需读取。 - 更残酷的一条：不在仓库里的东西，对 Agent 就不存在。Slack 讨论、Google Docs、同事脑子里的经验——对 Agent 而言全是黑洞。必须先把隐性知识显性化写进文件，Agent 才能用。
- 第三层——拆分的幻觉（作者踩过最深的坑）：作者看过太多”多 Agent 是趋势”的说法，于是搭了一套：一个 Agent 规划、一个写代码、一个测试、一个审查。Anthropic 的工程博客直接把他打醒：按人类组织结构拆分 Agent 是最低效的方式——写测试的 Agent 不知道实现 Agent 为什么这么写，做审查的 Agent 不了解前面排除过什么方案，它们之间反复解释背景消耗的 Token 甚至超过了真正干活的 Token。正确的拆分方式是以上下文为中心：只有当两个任务的上下文可以真正隔离时，拆分才有意义，否则就是在造一个分布式单体。
- 认知顺序即课程结构：作者把 100+ 篇笔记按”工程师搭建 Agent 系统时的真实认知顺序”重组，而不是按论文结构或技术栈分类——第一个模块回答”为什么”（为什么 Agent 时代需要新的工程范式），中间模块回答”怎么想”（上下文怎么管、架构怎么选、能力怎么封装），最后两个模块回答”怎么干”（怎么评估质量、怎么上线运营）。并配了一个贯穿全程的端到端案例：自动化竞品分析 Agent 系统（从仓库怎么组织、上下文怎么管理、用哪种 Workflow 模式，到怎么评估报告质量、怎么灰度上线）。
- 趋势判断与入门建议：作者类比三年前的 Kubernetes / Service Mesh——当时也觉得是大厂专属，如今不会 K8s 的后端工程师越来越难找工作。Agent 现在处于早期红利期。三条建议：先跑起来（用 Cursor 或 Claude Code 做一个小项目，别纠结理论）；把踩坑当学习（Agent 犯蠢时去想”它为什么会这样”）；犯错成本极低（让 Agent 改代码几秒钟就好，大胆试、快速迭代）。结论句：学会用 Agent 的工程师不会被 Agent 取代，真正危险的是拒绝学习的人。
实操内容保留
本文是认知/观点类文章，无代码块与 Prompt 模板。以下保留原文中可直接复用的工程判断与自检项。
代码/配置
（本文无实操代码/配置）
Prompt 模板
（本文无 Prompt 模板）
操作步骤
① Agent 环境三层诊断清单（把”环境”抽象拆成可检查的三层）
| 层次 | 症状 | 修法 |
|---|---|---|
| 感知层 | Agent 写完就停，从不自己验证 | 接入可观测面：浏览器（Chrome DevTools Protocol）、日志查询、监控，让系统状态对 Agent 可见 |
| 知识层 | 指令越多表现越差；隐性知识用不上 | 小 agents.md 当目录 + 结构化子目录按需读取；把 Slack/Docs/口头经验显性化写进仓库 |
| 架构层 | 多 Agent 互相解释背景，同步开销压过并行收益 | 以上下文为中心拆分；上下文不能真正隔离就不要拆 |
② 上下文组织原则（OpenAI 原话的可执行版本）
- 把
agents.md写成一个目录，而不是说明书——只放索引和导航。 - 详细知识拆进结构化的子目录，Agent 按需读取。
- 不要把所有条目都标为”重要”——全都重要等于什么都不重要。
- 判断标准：不在仓库里的知识，对 Agent 等于不存在。
③ 多 Agent 拆分决策
- 先问：这两个任务的上下文能否真正隔离？
- 能 → 拆成独立 Agent；不能 → 保持单 Agent，用 Workflow 管理内部流程。
- 反面教材：规划 / 编码 / 测试 / 审查四角色按人类组织结构拆分。
④ 新手入门三步（作者建议）
- 先跑起来：用 Cursor 或 Claude Code 做一个小项目，感受 Agent 怎么干活，别纠结理论。
- 踩坑就是学习：Agent 犯蠢时追问”它为什么会这样”——这个思考过程就是理解 Agent 的过程。
- 大胆试、快速迭代：Agent 时代犯错成本极低，几秒钟就能改回来。
⑤ 作者自建教程结构（7 模块，可作为学习路径参考）
- 模块 1：回答”为什么”——为什么 Agent 时代需要新的工程范式
- 中间模块：回答”怎么想”——上下文怎么管、架构怎么选、能力怎么封装
- 末尾两个模块：回答”怎么干”——怎么评估质量、怎么上线运营
- 贯穿案例：自动化竞品分析 Agent 系统（仓库组织 / 上下文管理 / Workflow 模式 / 报告质量评估 / 灰度上线）
关键概念
- 上下文工程 — 本文第二层的核心：管理”喂给模型的上下文”，“给地图而不是说明书”
- Coding Agent — 全文的引子案例：Demo 惊艳、上线两周后因环境污染而崩坏
- 多Agent架构 — 本文第三层：按人类组织结构拆分是最低效的方式
- AGENTS.md 规范文件 — 第二层中被塞到 5000 行反而拖垮表现的那个文件
- 上下文漂移 — 第一、二层失败现象的共同后果：架构漂移速度超过修补速度
- AI 执行环境 — 本文的母题：“环境”具体包含感知面、知识面、架构面
- Agent Harness — OpenAI 把 Chrome DevTools Protocol 接入运行时的做法，是 Harness 层的改造
- OpenAI — Codex 团队的”Agent 看不见系统状态”与”给地图不给说明书”均出自其复盘
- Anthropic — 多 Agent 研究系统给出”按人类组织拆分最低效”的结论
- LangChain — 上下文工程系列是作者的第二处素材来源
- Chrome DevTools Protocol — 让 Coding Agent 能打开应用、截图、看 DOM、查日志的接入点
- 分布式单体 — 上下文不可隔离却强行拆分多 Agent 的后果
与其他素材的关联
- 与 2026-06-17-ai-agent-工程完全指南 的关系：同一篇文章的两个抓取版本，互为校准与补充。那篇来自
raw/extracts/20260617-075211/juejin.cn/100-ai-agent.md（baoyu extract，带作者署名与发布时间，结构完整）；本页来自 2026-06-10 的 Telegram 抓取raw/articles/2026-06-10-125558-tg-0e4f81.md（http_capture 预取正文，无署名元数据）。两者共享全部三层论点；本页保留了原文里更直白的表述（“修完一个冒出两个”、“分布式单体”、作者的自建 7 模块课程结构与入门三步建议）。引用时两者不应被当作两篇独立素材叠加计数。 - 与 2026-06-10-agent-engineering-guide 的关系：同一 raw 的前一次落盘。那篇的
source_path指向raw/articles/2026-06-10-agent-engineering-guide.md（另一份 raw），与本页的2026-06-10-125558-tg-0e4f81.md不是同一文件；本页是该次 ingest 未完成时的重新落盘。 - 与 2026-07-01-woshipm-multi-agent-coding-pipeline 的关系：抽象原则 ↔ 可落地规范。本篇说”按人类组织拆分是多 Agent 的幻觉、要以上下文为中心拆分”；那篇把同一原则做成了可执行的工程规范（主智能体 + 子智能体的交接、允许改哪里、如何验证、失败怎么修、怎么交付证据），并给出”任务能在一个上下文里清楚完成就不要启用多智能体”的判断标准。
- 与 2026-07-05-juejin-context-engineering-harness 的关系：同一命题的不同入口。本篇从”环境”这个抽象词出发，拆成感知/知识/架构三层；那篇直接落在”上下文工程 + Harness”这一具体工程层，正好是本篇第二、三层的实现细节。
- 与 2026-05-27-juejin-claude-code-5-tools、2026-05-13-ai-agent-productivity-20x 的关系：共同定义 上下文工程。本篇贡献的是”上下文有限、标记全都重要等于什么都不重要”这条约束，以及”不在仓库里就不存在”的显性化要求。
原文精彩摘录
上线两周后，Agent 开始犯蠢。不是它变笨了。是它自己写出来的代码慢慢污染了自己的环境——它复制了一处不符合规范的实现，然后在后续任务里又复制了三处。架构漂移的速度比你修补的速度还快。我花了一整周手把手修 Bug，修完一个冒出两个。那一刻我才明白：问题根本不在 Prompt 上。
我读到这段的时候，突然理解了一件事：我们一直在调 Prompt，但真正的杠杆在 Prompt 之外。Agent 需要的不是更聪明的指令，而是能感知环境的基础设施。
结果完全反直觉：指令越多，Agent 表现越差。原因很简单——上下文是有限的。你塞了 5000 行规则进去，留给任务本身的思考空间就被挤掉了。而且所有东西都被标记为”重要”，等于什么都不重要。
结果 Anthropic 的工程博客直接把我打醒了：按人类组织结构拆分 Agent，是最低效的方式。写测试的 Agent 不知道实现 Agent 为什么这么写，做审查的 Agent 不了解前面排除过什么方案。它们之间反复解释背景消耗的 Token，甚至超过了真正干活的 Token。多 Agent 的正确拆分方式是以上下文为中心——只有当两个任务的上下文可以真正隔离时，拆分才有意义。否则你就是在造一个分布式单体。
学会用 Agent 的工程师不会被 Agent 取代。真正危险的是那些拒绝学习的人。