研究了半年 Agent，我终于搞懂了为什么大部分团队都在做无用功
作者花了半年研究 Anthropic、OpenAI、LangChain 等团队的工程复盘，提炼出 Agent 工程的三层认知翻转：Agent 看不见环境、知识放错了地方、多 Agent 拆分方式错误。
基本信息
- 来源类型：article（网页文章）
- 原文位置：raw/articles/2026-06-10-agent-engineering-guide.md
- 原文 URL：https://juejin.cn/post/7619886405088690195
- 消化日期：2026-06-10
核心观点
-
Agent 的瓶颈不在模型，在环境：作者给内部项目搭了 Coding Agent，Demo 阶段惊艳，上线两周后 Agent 开始犯蠢——不是变笨了，是它自己写出来的代码慢慢污染了自己的环境，架构漂移的速度比修补速度还快。根本原因是 Agent 的运行环境缺乏规范和治理。
-
Agent “看不见”是第一层障碍：OpenAI Codex 团队发现早期 Coding Agent 写完代码就停了，不会自己验证。根本原因是 Agent 看不见系统状态——没有接入浏览器、日志查询、监控。接入 Chrome DevTools Protocol 后，Agent 能自己打开应用、截图、看 DOM、查日志，单次任务自主工作超过 6 小时。
-
知识放错了地方导致 Agent “变笨”：把所有规则塞进一个超长
agents.md会适得其反——上下文有限，塞了 5000 行规则，留给任务本身的思考空间就被挤掉了。正确做法是”给 Agent 一张地图，而不是一本一千页的说明书”——小的agents.md当目录，详细知识拆到结构化子目录，按需读取。 -
按人类组织结构拆分多 Agent 是最低效方式：Anthropic 工程博客指出，写测试的 Agent 不知道实现 Agent 为什么这么写，做审查的 Agent 不了解前面排除过什么方案。它们之间反复解释背景消耗的 Token 甚至超过了真正干活的 Token。正确拆分方式是以上下文为中心——只有当两个任务的上下文可以真正隔离时，拆分才有意义。
-
不在仓库里的东西对 Agent 就不存在：Slack 讨论、Google Docs、同事脑子里的经验——全都是黑洞。必须把隐性知识显性化写到文件里，Agent 才能用。
实操内容保留
代码/配置
（本文无实操代码/配置）
Prompt 模板
（本文无 Prompt 模板）
操作步骤
作者给出的学习建议：
- 先跑起来：用 Cursor 或 Claude Code 做一个小项目，感受 Agent 怎么干活。别纠结理论，先动手。
- 踩坑就是学习：Agent 会犯蠢，你会生气，然后你会想”它为什么会这样”——这个思考过程就是理解 Agent 的过程。
- 犯错成本极低：Agent 时代最大的变化是你让 Agent 改代码，几秒钟就改好了。大胆试，快速迭代。
关键概念
- 上下文工程 — 文章核心主题之一：Agent 需要的不是更聪明的指令，而是能感知环境的基础设施；知识需要结构化管理而非一股脑塞进 prompt
- AI Agent 智能体 — 文章讨论的核心对象，聚焦于 Agent 工程实践中的环境治理问题
- 上下文漂移 — 作者亲身经历的”架构漂移”本质就是上下文漂移——Agent 复制不规范实现并自我强化
- Hermes Agent — 文末推荐的学习教程（Hermes Engineering）对应的 Agent 框架
- AGENTS.md 规范文件 — 文章讨论的”给 Agent 一张地图”正是 AGENTS.md 的核心定位
与其他素材的关联
- 与 2026-05-28-agents-md-coding-standard 的关系：本文”知识放错了地方”的观点与莪_幻尘的 AGENTS.md 实践完全对齐——60-100 行的项目规范文件就是”地图”，详细知识拆到子目录就是”按需读取”
- 与 2026-05-31-blocktempo-7-agents-software-factory 的关系：本文”按人类组织结构拆分多 Agent 是最低效方式”与 @sairahul1 的上下文隔离视角互补——7 Agent 软件工厂的拆分逻辑正是”以上下文为中心”而非以人类职能为中心
- 与 2026-05-13-ai-agent-productivity-20x 的关系：本文”不在仓库里的东西对 Agent 就不存在”呼应了深思圈的上下文资产论——agents.md / memory.md / Skill / MCP 四类资产就是把隐性知识显性化的载体
- 与 2026-06-02-woshipm-agent-architecture-landing 的关系：本文从反面论证了 Agent 架构设计的重要性——环境治理失败的案例说明架构不是锦上添花而是地基
原文精彩摘录
跑 Demo 的时候特别惊艳——给一段需求描述，Agent 能自己读代码、写实现、跑测试、提 PR。整个过程行云流水。上线两周后，Agent 开始犯蠢。不是它变笨了。是它自己写出来的代码慢慢污染了自己的环境——它复制了一处不符合规范的实现，然后在后续任务里又复制了三处。架构漂移的速度比你修补的速度还快。
OpenAI 的 Codex 团队发现，早期的 Coding Agent 写完代码就停了——它不会自己去验证。不是不想，是它看不见系统状态。没有接入浏览器，没有日志查询，没有监控。他们后来做了什么？把 Chrome DevTools Protocol 接入 Agent 运行时。Agent 能自己打开应用、截图、看 DOM、查日志。做了这个改动之后，单次任务能自主工作超过 6 小时。
Anthropic 的工程博客直接把我打醒了：按人类组织结构拆分 Agent，是最低效的方式。写测试的 Agent 不知道实现 Agent 为什么这么写，做审查的 Agent 不了解前面排除过什么方案。它们之间反复解释背景消耗的 Token，甚至超过了真正干活的 Token。