本文探讨如何成为Agent工程师指出Agent开发是一种方向而非所有程序员的必选道路。作者强调应根据业务需求决定是否采用Agent技术而非盲目跟风学习。文章分享实际案例指出开发Agent时需关注业务场景如安全控制、任务管理等而非单纯的技术堆砌。同时提出利用Coding Agent学习源码但需结合业务需求验证方案有效性。最终作者建议关注业务问题而非纠结于技术标签。最近知乎有一个热帖怎么成为 Agent 工程师常见答案是一张学习路线图先学 Prompt再学 Skill、Tools、RAG、Memory接着研究工作流、部署和多 Agent。看多了这类讨论很容易把 Agent 工程师当成软件工程师在 AI 时代的必选方向。我不太认同。从工程角度看Agent 和 Web、App 一样都是用来解决业务问题的一类应用。Agent 有自己的工作方式也需要理解一些新的基本原理。但如果业务不需要 Agent就没有必要为了跟上潮流先把整套技术栈学一遍。Agent 开发是一种方向。借助 AI 解决问题是一种适用面更广的能力。我们最早以为问题出在 SkillOpenClaw 火的时候我们用它开发了几个 Skill解决一些业务问题。调优和测试时Skill 的执行经常不稳定。最开始我们也沿着最显眼的地方改继续调整 Skill补脚本增加规则。但改了一段时间我发现问题不在 Skill 这一层。在我们当时采用的 OpenClaw 方案里Tools 和 System Prompt 不能根据业务需要修改。默认 Tools 更偏个人助理而我们的 Agent 面向商家。商家场景需要更细的安全控制哪些文件能读哪些业务操作能执行。我们的批量任务运行时间很长如果没有任务管理经常执行到一半就会中断。继续研究 Skill 怎么写解决不了这些问题。我们后来转向 OpenClaw 的内核 Pi自己定义 Tools 和 System Prompt再根据业务需要建立安全控制和长程任务管理。后面的 Memory 和上下文管理也是这样来的。不是因为学习路线走到了这里而是测试又暴露了新的问题。用 Coding Agent 往源码里多追一层每次测试暴露一个新问题我都会用 Coding Agent 往源码里多追一层看看其他 Agent 是怎么处理的再回到自己的业务里验证。这段时间我其实是在用 Agent 学习 Agent。前一个 Agent 指 Coding Agent。我会让它研究其他 Agent 的源码找相似实现也会观察它如何理解代码和报错。需要做新模块时我还会让它结合业务约束写出第一版。它给出的解释只能当线索不能直接当结论。它对源码的理解对不对换到我们的场景还成不成立最后都要用测试和业务结果验证。Coding Agent 可以帮我理解实现但安全边界应该落在哪里长程任务怎样才不会中断Memory 到底该记什么仍然要根据业务来定。代码里没有现成答案。理解 Agent是为了知道该改哪一层无论最后做的是 Web、App 还是 AgentCoding Agent 都能参与读文档、研究源码、比较方案甚至写出第一版。但代码能运行不等于业务问题解决了。要判断 AI 给出的方案能不能用仍然要理解 Agent 眼下看到了什么、能调用哪些工具、工具返回的结果怎样影响下一步以及哪里必须由人设定边界。我也看到有些同学发现 Skill 对业务重要就一直研究 Skill、脚本和部署。可问题不在 Skill 层时规则和脚本加得再多Agent 还是会选错 Tool、记不住信息或者执行到一半停下来。先看业务需不需要如果业务需要 Agent就去做。如果业务不需要 Agent也没有必要为了跟上潮流先学完一整套 Agent 技术栈。我现在更关心的不是自己算不算 Agent 工程师而是业务出了问题时能不能借助 AI 把它追到应该解决的那一层。最后说一句技术成长不只是写代码职业规划和自我包装同样重要。我整理了一份简历、面试和职业规划的学习资料适合想在职场上走得更远的朋友看看。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。