AI不是工具，而是同事：Agentic Engineering正在重写工程师的工作方式

如果你还把AI当成“更聪明的搜索引擎”，你已经落后了。Brendan O'Leary在这场演讲中抛出一个反直觉观点：真正的AI工程，不是用AI写代码，而是像带新人一样“管理”AI。这不是比喻，而是一套正在成型的新工程范式。

最危险的误解：我们一直在“用”AI，而不是“和它共事”

Brendan一上来就点破了一个行业集体误区：我们把AI当工具，但它的行为模式早就越过了“工具”的边界。Agentic Engineering 的核心，不是提示词技巧，而是承认一个现实——你面对的更像是“另一个工程师”。

这个工程师有点怪：它读过“每一条 Stack Overflow 的回答”，却不一定理解你真正想解决的问题。于是，问题出现了：当我们把AI当成自动化工具时，失败看起来像模型不够聪明；但当你把它当成同事时，失败往往暴露的是——你没把问题讲清楚。

这个视角的转变非常关键。它直接把责任从“模型能力”拉回到“工程方法”本身，也解释了为什么同样的模型，有的人能做出系统级成果，有的人却只能生成零碎代码。

Agentic Engineering 的真相：你在管理“上下文”，不是在写 Prompt

在所有“战术层面”的讨论里，Brendan反复强调一件事：真正稀缺的能力，是上下文管理（Context Management）。

这听起来抽象，但他的类比非常接地气：想象你在带一个初级工程师。你不会只丢一句需求给他，然后祈祷结果正确。你会解释背景、约束、为什么这个问题重要、哪些路走过、哪些是禁区。

对AI也是一样。上下文不是一次性输入，而是一个持续被维护的工作记忆：我们在解决什么问题？当前的假设是什么？成功的标准是什么？哪些想法已经被否定？

当工程师抱怨“AI总是跑偏”，很多时候不是模型的问题，而是你根本没给它一个可以对齐的工作语境。Agentic Engineering 的第一原则，不是“更聪明的模型”，而是“更清晰的问题空间”。

像审查新人一样工作：先对齐问题，再对齐计划

Brendan 给出的流程，几乎完全复刻了资深工程师带新人的方式。

第一步，不是让AI直接动手，而是逼它复述问题：你理解我们在解决什么了吗？如果它的表述和你心里的版本不一致，现在就是最低成本的纠偏时刻。

第二步，是让AI给出计划，而不是代码。这个环节的价值在于：你作为人类工程师，可以快速判断它是否“想清楚了”。如果计划本身就站不住脚，代码写得再漂亮也是浪费。

只有在问题和计划都被人类审查通过后，才进入执行阶段。最后的代码审查，也不是形式，而是和审一个初级工程师的PR一样：关注思路、边界条件和失败模式，而不只是语法是否正确。

这不是流程洁癖，而是未来工程师的分水岭

Agentic Engineering 听起来像是“多此一举”，但它实际上在筛选未来的工程师类型。

一类工程师，追求的是“更快出结果”，把AI当加速器；另一类工程师，开始构建“可协作的智能体”，把AI当团队成员。前者在短期内看起来更高效，后者却在系统复杂度上拥有压倒性优势。

当AI越来越像一个能自主行动的实体时，工程的难点不再是“怎么写”，而是“怎么想清楚、怎么说清楚、怎么持续对齐”。这正是Agentic Engineering存在的意义。

总结

Brendan O'Leary 的这场分享，真正震撼的地方不在于某个技巧，而在于角色反转：AI 不再是你手里的工具，而是你需要负责的“工程对象”。

对AI从业者来说，最直接的行动建议只有一个：停止追求“一次性完美 Prompt”，开始建立上下文、问题澄清和计划审查的工作习惯。未来真正拉开差距的，不是谁用的模型更新，而是谁更像一个能带团队的工程师。

值得思考的是：当AI越来越像人，我们是否也需要重新学习，如何当一个好同事？

关键词： Agentic Engineering， AI Agent， 上下文管理， 人机协作， 工程方法论

事实核查备注： 需要核查：Brendan O'Leary 的演讲原话表述；“读过每一条 Stack Overflow 回答”的比喻是否为原句；Kilo 在演讲中的具体指代与上下文。