企业官网建设流程全解析

本文探讨如何成为Agent工程师，指出Agent开发是一种方向，而非所有程序员的必选道路。作者强调，应根据业务需求决定是否采用Agent技术，而非盲目跟风学习。文章分享实际案例，指出开发Agent时需关注业务场景，如安全控制、任务管理等，而非单纯的技术堆砌。同时，提出利用Coding Agent学习源码，但需结合业务需求验证方案有效性。最终，作者建议关注业务问题，而非纠结于技术标签。

最近知乎有一个热帖：怎么成为 Agent 工程师？

常见答案是一张学习路线图：先学 Prompt，再学 Skill、Tools、RAG、Memory，接着研究工作流、部署和多 Agent。

看多了这类讨论，很容易把 Agent 工程师当成软件工程师在 AI 时代的必选方向。

我不太认同。

从工程角度看，Agent 和 Web、App 一样，都是用来解决业务问题的一类应用。Agent 有自己的工作方式，也需要理解一些新的基本原理。但如果业务不需要 Agent，就没有必要为了跟上潮流，先把整套技术栈学一遍。

Agent 开发是一种方向。借助 AI 解决问题，是一种适用面更广的能力。

我们最早以为问题出在 Skill

OpenClaw 火的时候，我们用它开发了几个 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 还是 Agent，Coding Agent 都能参与读文档、研究源码、比较方案，甚至写出第一版。

但代码能运行，不等于业务问题解决了。

要判断 AI 给出的方案能不能用，仍然要理解 Agent 眼下看到了什么、能调用哪些工具、工具返回的结果怎样影响下一步，以及哪里必须由人设定边界。

我也看到，有些同学发现 Skill 对业务重要，就一直研究 Skill、脚本和部署。可问题不在 Skill 层时，规则和脚本加得再多，Agent 还是会选错 Tool、记不住信息，或者执行到一半停下来。

先看业务需不需要

如果业务需要 Agent，就去做。

如果业务不需要 Agent，也没有必要为了跟上潮流，先学完一整套 Agent 技术栈。

我现在更关心的，不是自己算不算 Agent 工程师，而是业务出了问题时，能不能借助 AI 把它追到应该解决的那一层。

最后说一句，技术成长不只是写代码，职业规划和自我包装同样重要。我整理了一份简历、面试和职业规划的学习资料，适合想在职场上走得更远的朋友看看。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。