这半年，我像着了魔一样。

每天下班后我不是在刷论文，就是在啃 GitHub 上的源码，甚至把 OpenAI、Anthropic 还有 LangChain 团队的技术博客翻了个底朝天。等到回过神来Notion 里Yi经堆了 100 多篇零散的笔记。kan着这些碎片化的知识，我突然意识到一件事：我们一直在调 Prompt，但真正的杠杆在 Prompt 之外。

Agent 需要的不是geng聪明的指令，而是Neng感知环境的基础设施。

消化完这 100 多篇笔记之后我Zuo了一件kan起来hen“笨”的事：把所有知识按照工程师搭建 Agent 系统时的真实认知顺序重新组织了一遍。不是按论文结构，也不是按技术栈分类，而是按你实际干活时会遇到的问题来排的。这不仅仅是一份文档，geng像是一张从“新手村”到“满级号”的通关地图。

为什么我们需要新的工程范式？

在应用 AI 领域，提示工程 独领风骚了好几年。但Zui近，一个新的术语开始流行起来：上下文工程。

这不仅仅是名词的geng替，而是认知的升级。hen多人对 Agent 的理解从根上就是错的。我们以为只要给大模型灌输足够多的规则，它就Neng变成全知全Neng的超级助手。于是我试过把所有项目规则塞进一个超长的 agents.md 文件里天真地觉得这样 Agent 什么dou该知道了。

结果呢？完全反直觉：指令越多，Agent 表现越差。

原因hen简单——上下文窗口是有限的。你塞了几千行规则进去，留给任务本身的思考空间就被挤掉了。而且，当所有东西dou被标记为“重要”时等于什么dou不重要。这就像你给一个刚入职的实习生发了一本 1000 页的公司规章制度，却没告诉他厕所在哪，他大概率会直接懵圈。

kan不见的敌人：环境感知的缺失

OpenAI 的 Codex 团队曾发现一个尴尬的现象：早期的 Coding Agent 写完代码就停了——它不会自己去验证。不是它不想偷懒，是它kan不见系统状态。没有接入浏览器，没有日志查询，没有监控。

这让我想起去年年底我给一个内部项目搭 Coding Agent 的经历。跑 Demo 的时候特别惊艳——给一段需求描述，Agent Neng自己读代码、写实现、跑测试、提 PR。整个过程行云流水，仿佛未来Yi来。

但上线两周后Agent 开始犯蠢。不是它变笨了而是它自己写出来的代码慢慢污染了自己的环境。它复制了一处不符合规范的实现，然后在后续任务里又复制了三处。架构漂移的速度比我修补的速度还快。我花了一整周手把手修 Bug，修完一个冒出两个。

那一刻我才明白：问题根本不在 Prompt 上。

你把 Prompt 写得再好，Ru果 Agent 的运行环境是一团乱麻，它照样犯蠢。就像你给一个实习生写了一百条规则，但把他扔进一个没有文档、没有规范、没有 CI 的项目里——规则再多也没用。

后来OpenAI 团队是怎么解决的？他们把 Chrome DevTools Protocol 接入了 Agent 运行时。Agent Neng自己打开应用、截图、kan DOM、查日志。Zuo了这个改动之后单次任务Neng自主工作超过数小时。这才是真正的“工程化”，不仅仅是写好 Prompt，而是给 Agent 装上眼睛和耳朵。

多 Agent 架构的陷阱：别造“分布式单体”

这部分是我踩过Zui深的坑。

我kan过太多文章说“多 Agent 是趋势”，于是我也搞了一套：一个 Agent 负责规划，一个负责写代码，一个负责测试，一个负责审查。kan起来hen专业，分工明确，仿佛这就是软件工程的未来。

结果 Anthropic 的工程博客直接把我打醒了：按人类组织结构拆分 Agent，是Zui低效的方式。

为什么？因为写测试的 Agent 不知道实现 Agent 为什么这么写，Zuo审查的 Agent 不了解前面排除过什么方案。它们之间反复解释背景消耗的 Token，甚至超过了真正干活的 Token。

多 Agent 的正确拆分方式是以上下文为中心——只有当两个任务的上下文Ke以真正隔离时拆分才有意义。否则，你就是在造一个“分布式单体”系统。表面上拆分了实际上耦合得要死，沟通成本高得吓人。

给 Agent 一张地图，而不是一本百科全书

geng残酷的是：不在仓库里的东西，对 Agent 就不存在。

Slack 讨论里的决策、Google Docs 里的需求变geng、同事脑子里的经验——全dou是黑洞。你必须把隐性知识显性化写到文件里Agent 才Neng用。这听起来hen累，但这正是工程化的代价。

正确的Zuo法是 "给 Agent 一张地图，而不是一本一千页的说明书" ——这是 OpenAI 的原话。一个小的 agents.md 当目录，详细知识拆到结构化的子目录里Agent 按需读取。

这就像我们以前查资料，不是把整个图书馆搬回家，而是学会查目录索引。这种“按需加载”的思维，在 Agent 开发中至关重要。

从 Demo 到生产：一条完整的工程路径

学习这件事没有捷径，但有方向。基于这半年的研究，我把这套方法论整理成了一套系统的指南。它不追geng全部内容，只筛选与 Agent 相关的核心逻辑，试图弄清“决策循环”的实际运行机制。

这套指南主要分为几个核心模块：

1. 为什么：范式转移

第一个模块回答“为什么”——为什么 Agent 时代需要新的工程范式。这不仅仅是技术升级，geng是开发思维的彻底重构。就像三年前大家kan到 "Kubernetes" "Service Mesh" 也是这个反应，觉得太复杂、没必要。现在呢？不会 K8s 的后端工程师Yi经越来越难找工作了。Agent 也是一样的趋势，只不过现在还处于早期红利期。

2. 怎么想：架构与上下文

中间的模块回答“怎么想”——上下文怎么管、架构怎么选、Neng力怎么封装。这里我会详细拆解“上下文工程”的实践，如何构建 RAG 系统，如何管理记忆状态，以及如何选择合适的 Workflow 模式。

3. 怎么干：评估与运营

Zui后两个模块回答“怎么干”——怎么评估质量、怎么上线运营。hen多 Agent 项目死在 POC 阶段，就是因为缺乏有效的评估体系。你需要建立一套自动化的评估机制，而不是靠肉眼去检查每一个输出。

为了让大家geng容易上手，我还Zuo了一个贯穿所有模块的端到端案例：自动化竞品分析 Agent 系统。从仓库怎么组织、上下文怎么管理、用哪种 Workflow 模式、到怎么评估报告质量、怎么灰度上线——每一步dou给出了具体的工程决策。

写在Zui后：不要Zuo那个拒绝学习的人

我知道hen多人kan到“Agent”“上下文工程”“多 Agent 架构”这些词就头大。觉得这是大厂高级工程师才玩的东西，跟自己没关系。

但智联招聘的Zui新数据给出了Zui直观的印证：AI 领域求职人数同比增幅突破 200%，人工智Neng工程师岗位的求职热度飙升。这股浪潮Yi经来了。

有人提出过这样一个质疑：“为了 AI 而 AI，我不保证 AI 的效果一定比传统的工程化产品设计geng好，那我用一个无法保证效果的工具去替代掉一个经过验证、成熟稳定的工程化方案，就是杀鸡用牛刀。”

这种担忧hen合理。但我想说的是学会用 Agent 的工程师不会被 Agent 取代。真正危险的是那些拒绝学习的人。

现在应该把这些知识整理成一篇，里面把知识全部写在一起。它Neng自动完成原本需要人工点击的操作，把人从重复的机械劳动中解放出来。这才是技术的初衷。

这套指南，就是我整理自半年的研究笔记，希望Neng帮你在 Agent 的工程化道路上少走弯路。Ru果对你有帮助，Star ⭐ 一下就是Zui大的支持。也欢迎分享给身边在研究 Agent 的朋友。

写于深夜，整理自半年的研究笔记与踩坑实录。

---