> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# 代理工程才是未来
- URL: https://www.hubwiz.com/blog/agentic-engineering-is-the-future/
- Published: 2026-05-19T11:59:09.000Z
- Updated: 2026-05-19T11:59:09.000Z
- Description: 新的工作流不同了。我不让AI替我思考。我掌控架构、产品方向、约束和审查流程。AI写大部分代码，但我设计围绕它的系统。
- Author: admin
- Tags: VIBE CODING, #Import 2026-10-14 14:41

在过去的几个月里，我与编程的关系彻底改变了。

我不再是"用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、审查循环才是魔法发生的地方

我工作流中最强大的部分不是代码生成。

而是审查循环。

基本流程是这样的：

1. 用代理构建一个小功能。
2. 在本地测试。
3. 打开一个小PR。
4. 运行AI代码审查。
5. 将审查结果反馈给代理。
6. 让代理修复问题。
7. 重复直到审查通过。

这就是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.](https://medium.com/@EthanCooperwrtier/vibe-coding-is-over-agentic-engineering-is-the-future-8f0377c69fca?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处