驾驭工程、上下文工程与运行时控制，Agent编程方法论的五根支柱

工具半年换一轮，迭代速度只快不慢。

去年很多团队的主力还是 Cursor，今年已经切到 Claude Code 和 Codex。每次换工具，之前攒的操作技巧大半作废。但有一件事我从第一天起就没重学过，让 Agent 按我的规矩干活的那套方法论。

这套方法论由五根支柱撑起，驾驭工程、上下文工程、项目记忆、提示词工程、运行时控制。这篇把它们作为一个体系讲清楚，帮你把「会用工具」升级成「能驾驭 Agent」。

大多数人卡在哪

大多数人学 Agent 编程，停在「会用工具」这一层。装好了，跑几个任务，出了结果。

然后遇到复杂项目就现原形。Agent 会干偏、会忘事、会越权、会在关键步骤做出你没预料的判断。团队开始互相传颂各种玄学技巧，但问题从来没被系统解决。

问题不在工具，在于没有人给 Agent 建立规矩。这个领域有三个概念经常被混用，先把关系理清。

提示词工程，关注单次对话怎么写指令。它是起点，但解决不了跨会话记忆、权限控制、团队协同这些持久化问题。上下文工程，关注在正确的时间把正确的信息喂给 Agent，范围涵盖项目记忆、动态检索、工具结果注入的整条信息供给链。驾驭工程，实践者从一线总结出的总纲，把 Agent 当作一个需要管理的新员工，用规范、上下文、权限和扩展机制建立完整管理体系。

提示词工程是「怎么说一句话」，上下文工程是「怎么让它看到对的信息」，驾驭工程是「怎么让它长期可靠地干活」。三者是包含关系，不是并列关系。

驾驭工程，把 Agent 当新员工管理

驾驭工程的核心思想一句话就能说完，不要逐句指挥 Agent 做什么，要建立一套体系让它自己干活。

想象你招了一个新员工。你不会每分钟告诉他现在打开哪个文件删第几行。你会做三件事，给他一份入职手册，带他熟悉项目，告诉他什么事能自己定、什么事必须先问你。

这个类比的好处是，它把你已经会的管理经验直接迁移过来。你管理人类团队踩过的坑，几乎能原样对应到 Agent 管理上。新人不培训就上岗，必然闯祸。规矩只说不写下来，新人必然装听不见。权限一把梭，出事连责任都追不到。这些人类管理的常识，就是驾驭工程的全部起点。

落到工程上，这套管理体系分四层。规范层，Agent 该遵守什么规矩，载体是项目记忆文件。信息层，Agent 该看到什么信息，靠上下文工程供给。指令层，单次任务怎么表达清楚，这是提示词工程的地盘。边界层，Agent 能做什么不能做什么，由权限和沙箱组成的运行时控制管住。

四层协同才有效。举个例子，你让 Agent 给项目加一个用户认证模块。只有指令层没有规范层，Agent 可能花两小时从头自建一套认证，而你的记忆文件里明明写了用现成方案。只有指令层没有边界层，Agent 可能在你没注意的时候改了数据库结构。

传统软件工程管的是代码，驾驭工程管的是一个有自主判断能力的执行者。代码不会自作主张，Agent 会。所以驾驭工程的核心挑战不是写逻辑，而是约束判断。

上下文工程，在正确的时间喂正确的信息

Agent 干偏的原因，大多数时候不是它笨，是它瞎，你没把它需要的信息喂进去。

上下文工程的核心逻辑一句话，在正确的时间，把正确的信息，以正确的格式，喂给 Agent。这三个「正确」每个都有讲究。

正确的时间，不是一股脑全塞进去。上下文窗口有限，信息太多反而干扰判断。永久有效的信息写进记忆文件，会话级的信息放系统提示词，按需触发的用工具调用动态检索，实时产生的靠执行结果注入。

正确的信息，不是越多越好。Agent 最需要的是四类，技术栈和架构决策、编码规范和约定、已知的坑和绕法、当前任务的上下文。

正确的格式，同样的信息，结构化表达比自然语言更容易被准确理解。配置偏好用 YAML，选项对比用表格，提示词模板用代码块。一条好的上下文注入，格式占一半功劳。

这里有个高频误区要点名，把上下文工程等同于 RAG。RAG 只是从外部知识库检索信息这一种实现手段。上下文工程的范围大得多，涵盖项目记忆、系统提示词、动态检索、工具结果注入、会话历史管理的整条链。把 RAG 等同于上下文工程，就像把搜索引擎等同于互联网。

说到底，上下文工程还有个持久化问题要解决，项目记忆。

上下文工程解决喂什么，项目记忆解决怎么让信息持久化。

Agent 有个本质缺陷，无状态。每次新会话启动，它对你的项目一无所知。技术栈偏好、编码约定、架构决策、历史踩坑，全要重新交代。靠手打提示词传递，效率极低且必然遗漏。

解法就是项目记忆文件。Claude Code 用 CLAUDE.md，Codex 用 AGENTS.md，各家名字不同，本质一样，把项目规范写成 Agent 能读懂的文件，每次启动自动加载。

设计这类文件的经验有三条。第一，分层层加载，全局配置管通用习惯，项目根管项目铁律，子目录管模块专属规则，越靠近工作位置的越优先。第二，控制体积，这类文件有大小上限，超限会被截断，所以只写关键铁律，别写成回忆录。第三，改动走评审，多人协作时规矩文件的修改要经过评审再合并，防止一个人单方面改了全队的规矩。

运行时控制，管住行为边界

前面三层解决「干得好」，这一层解决「不出事」。

运行时控制三件套。上下文窗口管理，决定 Agent 一次能看多少信息，装太多了注意力稀释，装太少了两眼一抹黑，这个平衡要按任务类型调。思考模式，控制它做多深的推理再动手。简单任务开深度思考纯属浪费时间和额度，复杂架构决策不开深度思考就是让它裸奔。权限和沙箱，规定它能碰什么、不能碰什么、危险操作要不要人工审批，读文件给宽，改文件给窄，删库和对外发送永远要人批。

三件套的配置不是一次性的。项目初期权限从紧，跑熟了逐步放宽；涉及生产数据和客户环境的任务，永久保持最高管控档位。这些配置本身也要进版本管理，谁改的、为什么改，都有据可查。

企业场景里这一层是重中之重。只配能力不配边界的 Agent，等于给了新员工全部系统权限却不发员工手册，它能干活，也能闯祸，而且你不知道它闯了祸。

五根支柱拼起来

回看整个体系。规范层定方向，信息层给燃料，指令层驱动执行，边界层防越权，项目记忆让这一切跨会话持久。缺任何一根，Agent 的输出质量都会塌一角。而这五根支柱里，有四根的建设材料只是普通的文本文件，成本几乎为零，唯一的成本是你真的坐下来把它们写清楚。这份成本，任何团队都付得起。

工具是耗材，方法论是资产。怎么管理一个有自主判断能力的执行者，这门手艺不会因为换了工具就作废。

可能有人会问，这套东西是不是过度工程了，直接用不就行了。

我们的对比数据说明一切。同样给团队配 AI 编程工具，有体系的小组两周内产出稳定，没体系的小组三周后还在互相转述各种翻车故事。差距不在工具熟练度，在有没有人给 Agent 立规矩。

老雷给 FDE 同行的建议是，把这套五支柱框架直接搬进你的交付方法论。给客户做 AI 项目时，方案文档里有没有这五层的对应设计，基本能判断这个交付是玩具还是工程。你在其中积累的每一个记忆文件模板、每一份权限配置、每一条上下文策略，都是不会随工具迭代贬值的真资产。

写着写着想到驯马。人类驯化马匹用了几千年，缰绳、马鞍、马蹄铁，每一件发明都不是为了限制马的力量，而是为了让那份力量可以被信任、被指引、被用在该用的地方。

Agent 就是这个时代的新马。五根支柱，就是它的鞍和缰。