代理工程才是未来
在过去的几个月里，我与编程的关系彻底改变了。
我不再是"用AI写代码"了。这个说法已经过时了。我现在真正在做的是编排代理。
旧的工作流很简单：打开聊天机器人，输入提示，获取一些代码，粘贴到项目中，然后祈祷它能工作。有时确实能。有时则是一场调试噩梦。
那就是氛围编程。
它很有趣。很令人印象深刻。但也一团糟。
新的工作流不同了。我不让AI替我思考。我掌控架构、产品方向、约束和审查流程。AI写大部分代码，但我设计围绕它的系统。
这就是我所说的代理工程。
我认为这就是软件发展的方向。
1、模型很重要，但约束框架更重要
大多数人仍然在问错误的第一个问题。
他们问：
"我该用哪个模型？"
当然这很重要。更强的模型产生更好的结果，尤其是在大型代码库、重度架构任务和棘手的重构上。
但更大的突破是约束框架。
模型本身并不能真正做任何事情。它预测token。它不会自己读取文件、搜索仓库、运行测试、打开pull request或检查错误。
约束框架给了它这些能力。
像Cursor、Claude Code和Codex这样的工具不仅仅是编辑器或聊天窗口。它们是围绕模型的执行环境。它们为模型提供工具、文件访问、搜索、终端执行、项目记忆、系统提示和反馈循环。
这就是为什么同一个模型在不同的地方使用感觉完全不同。
在我当前的工作流中，Cursor是主要的约束框架。我喜欢它因为我可以快速切换模型，保持代理接近代码库，并使用其代理工作流而不需要不断与环境抗争。
对于更大的后端或重度架构工作，我使用可用的最强推理模型。对于UI和前端润色，我经常切换到更擅长视觉和界面级变化的模型。
教训很简单：
弱约束框架中的强模型感觉受限。 强约束框架中的强模型感觉像一个团队。
2、上下文工程才是真正的技能
起初，我认为更多上下文总是更好的。
我会给代理巨大的文件、长长的指令、完整的文档转储和庞大的项目摘要。道理很明显：如果AI知道更多，它应该表现更好。
但实际上并非如此。
过多的上下文使代理变差。它开始丢失信号。它关注不相关的细节。它基于噪音做出自信的决定。
现在我尝试给代理更少的上下文，但更好的上下文。
这意味着我准确地告诉它我想要什么、在哪里看、哪些文件重要、需要尊重什么约束、什么不要碰。
一个好的提示不是励志演讲。它是一份有范围的工程简报。
当我开始一个新功能时，我通常先让代理创建一个计划。但我不会盲目接受这个计划。我像一位资深工程师审查初级开发者的提案一样阅读它。
如果计划太大，我就缩小它。
我问：
"我们能把这个PR做得更小吗？" "这个变更的最小版本是什么？" "哪些文件真的需要改变？" "什么可以推迟？"
仅这一个习惯就极大地改善了我的结果。
当任务小、结果清晰、上下文精确时，AI代理的表现要好得多。
氛围编程把思考交给了代理。 代理工程把思考保留给了人类。
这个区别很重要。
3、源代码优于文档
我工作流中最大的变化之一是我如何给代理提供外部上下文。
我不再仅仅依赖文档。
文档是有用的，但它往往不完整、过时、简化，或者是为已经理解周围假设的人类编写的。
代码不同。
代码是真相的来源。
如果我在使用一个开源库、框架或工具，我经常将实际的仓库拉到我的项目中作为参考材料。然后我告诉代理：
"在实现功能之前参考这个代码库。"
这非常有效。
代理不会幻想API或猜测某物应该如何工作，它可以检查实际的实现。它可以搜索真实的函数、真实的类型、真实的使用模式和真实的边界情况。
这在处理快速发展的工具时尤其有用。
如果我在使用一个新库，我不希望代理依赖旧的训练数据或过时的博客文章。我希望它查看实际代码。
这也改变了我对开发工具的看法。
在AI原生工作流中，开源变得更有价值。如果代理可以检查源代码，它就能更准确地使用该工具。
对代理来说最好的文档往往不是markdown页面。
而是仓库本身。
4、AI写得快，但它也会制造混乱
每个AI辅助的代码库最终都会遇到一个问题：
AI喜欢写新代码。
它并不总是重用已有的东西。它可能创建一个新的helper而不是使用旧的。它可能跨文件复制逻辑。它可能以三种不同的方式在三个不同的功能中解决同一个问题。
起初，这感觉不像是大问题。
功能能用。演示看起来不错。代理说一切都完成了。
但随着时间的推移，代码库开始散发出不好的味道。
你得到重复的运行时机制、分散的业务逻辑、重复的API包装器、不一致的命名，以及几乎做同样事情但又不完全相同的函数。
这就是为什么工程纪律变得更加重要，而不是更不重要。
在用AI构建一个功能后，我通常会进行一次清理。我要求代理查找重复，提取可重用的服务层，将领域逻辑与基础设施逻辑分离，并简化实现的结构。
提示通常听起来像这样：
"审查此功能中是否有重复的逻辑和服务层提取的机会。" "将重复的运行时机制移到结构化模块中。" "保持领域策略与基础设施关注点分离。" "重构这段代码，使新的代理会话能快速理解它。"
这很重要，因为AI以后还需要在这个代码库上工作。
如果结构混乱，下一个代理会话会困惑。如果结构干净，代理可以更快地接手。
老派的工程原则并没有死。它们现在更重要了。
干净的模块。 小函数。 清晰的边界。 可重用的服务。 测试。 一致的命名。
这些以前是为人类准备的。
现在也是为代理准备的。
5、审查循环才是魔法发生的地方
我工作流中最强大的部分不是代码生成。
而是审查循环。
基本流程是这样的：
- 用代理构建一个小功能。
- 在本地测试。
- 打开一个小PR。
- 运行AI代码审查。
- 将审查结果反馈给代理。
- 让代理修复问题。
- 重复直到审查通过。
这就是Greptile等工具变得有价值的地方。
如果审查说PR是3分（满分5分），我不会立即手动修复一切。我让代理阅读反馈，理解问题，修补代码，然后推送修复。
然后审查再次运行。
如果提高到4分，代理继续。
循环持续到PR足够好可以合并。
但有一个重要的规则：
PR必须小。
如果我给代理一个10,000行的PR，我是在自找麻烦。审查变得嘈杂，修复变得有风险，代理失去了目标。
小的PR使循环正常工作。
这是最大的思维方式转变之一。我不再只是让AI生成代码。我在设计一个系统，让AI可以在受控循环中生成、审查、修复和验证代码。
这就是代理工程。
6、人类仍然需要掌权
人们犯的最大错误是过度信任代理。
AI即使在错误的时候也是自信的。它会愉快地建议一个没有严重问题的代码库有十个问题。如果你以一种引导它的方式措辞提示，它可以为糟糕的架构决策辩护。
这就是为什么我从不把代理当作最终权威。
我更愿意把它当作一个拥有巨大记忆的非常快的初级开发者。
它知道很多。 它可以快速行动。 它可以产出有用的工作。 但它需要方向。
人类仍然拥有判断力。
我决定构建什么。 我决定任务应该有多小。 我决定哪些权衡是可以接受的。 我决定架构是否有意义。 我决定输出什么时候准备好。
AI可以写90%的代码，但这不意味着它应该做90%的决定。
这就是把AI当作工具使用和被AI牵着走的区别。
7、选择对代理容易理解的工具
AI也改变了我评估技术栈的方式。
我现在问一个新问题：
"这个工具对代理友好吗？"
如果一个后端系统需要大量的仪表盘点击、隐藏配置或手动UI设置，代理就很难理解。
如果一切都用代码表示，代理可以检查它、修改它并对其进行推理。
这是一个巨大的优势。
我更喜欢那些模式、API、定时任务、权限和业务逻辑都在代码库中的工具。代理能看到的东西越多，它的表现就越好。
这也是为什么我喜欢保持接近简单原语的框架和库。HTML、TypeScript、显式API、清晰的文件结构——这些东西帮助代理。
开发者体验的未来不再仅仅关乎人类了。
它也关乎代理体验。
一个对代理来说容易检查和修改的工具在AI原生开发工作流中将变得更有价值。
8、安全不再是可选的
这一切还有更黑暗的一面。
如果AI代理能帮助我们更快地构建，它们也能帮助攻击者更快地行动。
这意味着安全习惯必须改善。
对开发者来说，软件包安装是最大的风险领域之一。恶意包或被篡改的版本可以快速造成严重问题，特别是如果代理在没有足够审查的情况下安装依赖项。
我现在喜欢的一条规则是：
不要安装发布不到14天的包。
这并不完美，但它减少了对尚未被社区发现的新恶意包的暴露。
我还认为每个认真的构建者都应该使用密码管理器，避免基于短信的两步验证，并小心本地开发环境中的凭据。
对于个人安全，AI语音和图像生成使骗局更具说服力。家庭暗语听起来很偏执，直到有人收到一个克隆语音消息要求汇款。
我们正在进入一个"我能看出来它是假的"不再是好的安全策略的世界。
更安全的假设是：
如果它可以被生成，它就可以被用来对付你。
9、比感觉舒适的速度更快地发布
AI使构建更快了。
这也意味着等待变得更加昂贵。
很多人永远卡在构建阶段。他们总是距离发布"还有两周"。然后六个月过去了，他们还是还有两周。
我理解这种本能。你希望产品更好。你希望入门流程更干净。你还想要一个功能、一个修复、一个润色。
但市场不关心你的私人路线图。
真正重要的唯一反馈来自于人们使用产品之后。
一个半功能的MVP在用户手中往往比一个没人碰过的漂亮私有构建更有价值。
行动最快的团队不是在等待完美。他们发布，收集反馈，修复坏掉的东西，然后重新发布。
你可以永远润色但仍然是错的。
或者你可以发布、学习、改进。
在代理时代，你的竞争对手不仅是在更努力地工作。他们在运行更多代理，测试更多想法，消耗更多token。
如果你等太久，别人会在你之前从市场中学到东西。
10、这不仅仅是关于开发者
最大的机会可能甚至不在软件工程中。
我认为知识工作即将被更加激进地转变。
合同。 会计。 研究。 报告。 内部运营。 客户支持。 数据清理。 电子表格。 合规工作流。
这些工作中很多对AI来说足够结构化可以进行辅助，但又足够混乱，公司还没有恰当地自动化它们。
这就是机会。
你不必是高级工程师才能从这一转变中受益。如果你能审视一个重复的工作流并想出如何用AI自动化其中的30%，你就变得更有价值了。
"我不懂技术"这句话正在变得危险。
不是每个人都需要成为软件工程师。但每个人都必须比今天更懂技术。
AI将触及每个行业。早期学会与它合作的人将拥有复合优势。
11、新的工作是编排
我越是用AI进行开发，我越是确信未来不在于提示。
提示只是表层。
更深的技能是编排。
你能清晰地定义结果吗？ 你能将工作分解到足够小的块吗？ 你能给代理正确的上下文吗？ 你能设计反馈循环吗？ 你能审查输出吗？ 你能保持代码库足够干净让下一个代理理解吗？
这才是真正的工作。
AI不会消除工程判断。它放大了良好判断的杠杆。
一个弱的工程师加上AI可以非常快地制造很多混乱。 一个强的工程师加上AI可以以难以置信的速度前进。
这就是为什么我认为"代理工程"是正确的框架。
它不是让AI接管。 它是构建一个人类掌权、代理以速度执行的系统。
氛围编程是关于看AI能做什么。
代理工程是关于设计AI应该怎么工作。
那些交付速度快100倍的人不会是那些在聊天机器人中输入随机提示的人。
他们将是那些通过干净的约束框架、紧凑的上下文、小的PR、自动化审查和清晰的反馈循环运行多个代理的人。
这就是我押注的未来。
原文链接：Vibe Coding Is Over. Agentic Engineering Is the Future.
汇智网翻译整理，转载请标明出处