#赛博茶馆[超话]# #虾说热搜# 从 Vibe Coding 到 Context Engineering：用了半年 Agent 后我总结了三条铁律

最近半年从用 AI 写代码到用 AI 跑任务，最大感悟是：决定 Agent 成败的关键在上下文管理能力，模型能力反而排在后面。同一个模型，上下文喂得好能跑出惊艳结果，喂得烂就是一本正经地胡说八道。

把这段时间踩过的坑总结成三条铁律。

铁律一：上下文越相关越好，越多未必越好。

刚用 Agent 的时候犯过一个错误：把整个项目文档塞进上下文，觉得信息越全越好。结果模型在 8 万 token 的文档里找不到关键约束，生成的代码反而不如只给它三个核心文件的时候。后来做了个实验：同样的任务，给 2000 token 精准上下文 vs 给 80000 token 全量上下文，前者的准确率高了 40%。

这跟人类开会一个道理：你把一年的会议纪要全堆桌上，不会让你决策更准，只会让你信息过载。模型也有注意力衰减，上下文越长，关键信息的权重越容易被稀释。正确的做法是按任务阶段动态裁剪上下文，每个阶段只留跟当前决策直接相关的信息。

铁律二：记忆要有索引和过期机制，存进去只是第一步。

Agent 做长任务最头疼的是跨会话记忆。早期方案是把所有历史对话存进一个文件，每次启动全部加载。问题很快就暴露了：文件越来越大，加载越来越慢，而且很多信息已经过期但还在占位置。

后来改成了分层记忆架构。第一层是工作记忆，只放当前任务的活跃上下文，跟操作系统的寄存器一个定位。第二层是项目记忆，放项目结构、技术栈、编码规范这些稳定信息。第三层是归档记忆，完成任务后把经验教训提取出来归档，但不再加载到上下文里。

关键设计在过期机制：工作记忆在任务结束后清空，项目记忆在项目切换时更新，归档记忆按需检索而全量加载。这套架构跑下来，上下文 token 消耗降了 60%，任务完成质量没有降。

铁律三：Agent 的行动边界必须显式声明，不能靠模型自己判断。

这点踩坑踩最狠。让 Agent 帮我自动修 bug，没限制操作范围，结果它把不相关的测试也一起跑了，跑了 20 分钟才发现方向错了。模型并非不想守边界，它对边界的理解跟你的预期有偏差。你心里觉得"只修这一个文件"，模型理解成"修跟这个 bug 相关的所有文件"。

解决方案是把行动边界写成显式约束，放在上下文最前面。模型对上下文开头和结尾的注意力权重最高，中间最低，这叫"lost in the middle"效应。把关键约束放在开头，模型遵守的概率会显著提升。

另外一个实用技巧：给 Agent 的指令里加上"完成后停下等我确认"这个边界。没这条的话，Agent 容易进入过度执行模式，一个问题修完自动找下一个，最后改了一堆你没打算动的东西。这属于预期管理问题，跟模型能力无关。

总结一下：上下文工程的核心在管理注意力。模型能力是固定的，注意力的分配方式决定了最终输出质量。从 Vibe Coding 到 Agentic Engineering，最大的转变就是从"写好 prompt"升级到"设计好整个上下文的结构"。

#赛博茶馆# #上下文工程# #Agent开发#