对AI应用开发的一些理解

Agent 应用开发是一个伪命题

我认为 Agent 应用开发是一个伪命题：我们今天做的各种各样的 Harness，在未来 1~2 年内就会被模型内化，变成模型自身的能力。

具体的表现是，我们之前会写很长的提示词，也会做一些 CoT 的技巧，比如强制让模型停下来，先把这一段的 Thinking 输出一遍，让模型更好地遵循指令、防止产生偏移；再往后还会做做基于 DAG 的 Workflow，来实现一个硬路径的编排。

但现在观察到的情况是，这些我们在 2025 年做的东西，到了 2026 年已经开始过时了——这些 Harness 部分的能力正在被模型内化。比如最新的 opus 5，它的system 已经删减了 80%链接长这样。而且从越来越多使用者的体验来看，复杂、冗余、繁长的提示词已经越来越不适用于今天的模型了，甚至会进一步拉低模型的表现。我们需要的是用更简短的提示词，简洁明了地说明具体步骤，然后让模型自己去执行。

另外一个有趣的现象是，以往的开发者会在提示词里写”确保正确”。在过去这可能很有用，但现在这样写可能会导致模型过度犹豫和反复验证，反而造成结果偏移。

今天的现象是，各种各样的 Harness 层出不穷，包括比较热的 Claude、Codex、pi、DeepSeek Harness，还有 ZCode、 kimi。这些都是非常同质化的产品，基本上大家都是你抄我，我抄你，你中有我，我中有你。最后更多的其实比拼的是谁背后的模型能力更厉害，甚至可以说我的 Harness 做的细节不够好，哪方面都欠缺一点，但是我有一个很强的模型，并且也会根据我的 Harness 进行一些训练，那么它的最后的效果其实远大于你对 Harness 做的一些优化和调整。

AI 全栈应用开发

当然，上面说的这些都是针对 Agent 应用开发。在我的理解中，AI 应用开发还有一类，叫”AI 全栈应用开发”：它不只是把 AI 能力集成到应用里，而是要求你借助 AI 工具来完成前端、后端，甚至 Agent 方面的开发。

这个方向我认为会有一定的前景，但更多依赖于业务需求。我们大部分的业务需求都来源于电商和各种各样的网站，它们需要前端和后端，但业务的增长不一定是无限的。过去可能需要很多人来跟上增长速度；而当已有代码能发挥大部分作用时，对应的人员需求就会变少。

因为 AI 在前端的上面的惊艳表现，以及AI可以写越来越多的代码，也要求着之前专职后端的人员转向全栈开发。

美术场景的落地实践

这些认知都基于我在腾讯IEG做技术美术时的观察。我的主要工作是搭建一套 Workflow，保证 Agent 在调用美术工具时能达到我们想要的效果。

我也尝试过做成类似 Codex 和 Claude Code 那样的创造类 Agent，但那样做的话，我没法给它提供合适的工具。原因在于，LLM 本身就是大文本模型，天然适用于代码的编辑和读写：只要把代码文本输入到大模型中，它就可以分析和修改，并且有方便的 Edit 工具精确地更改对应的段落。

但在美术类场景里，很多工具是我们自己写的，返回的也只是对应的 JSON 文件。这就带来一个问题：想看到最终效果图，就必须用截图工具给模型看图；而模型调用工具时，得到的返回值只有一个 ok——也就是这个工具运行成功还是失败，它只能通过截图来观察工具最终得到的效果。

这又引出多模态的问题。在真正的生产工具里，我们一般不会用很贵的模型，比如 GPT-6 或者 Claude 5.5 这个级别，大部分用的都是 Gemini Flash 这类轻量模型。而轻量模型没办法准确识别画面中细微的改变，这就导致很难把美术 Agent 做得像代码开发工具那样具有创造性——比如让模型自己去判断哪里该加多一点、哪里该加少一点。毕竟工具也是我们自己写的，不像代码的 Edit 工具那样可以精确地更改到某一个字母。

所以在美术场景里，我只能做相对固定的流程：让模型在我规定好的框架内准确地执行好每一步，发挥它应有的作用。也就是说，我们去掉了上下限，保中限。在这样的背景下，我做了一套基于 DAG 无环设计的 Workflow，整个框架基于 LangGraph 搭建。当然，这个是后话了。

未来不会有专职的 Agent 应用开发岗

回到最开始的主题。我认为未来不会有专职的 Agent 开发岗，而是要求每个行业的开发者都具备一定的 Agent 开发能力。

原因是 Agent 开发相对扁平化，壁垒很低：它的核心就是一个 Loop，所有后续功能都是基于这个 Loop 不断开发的，包括添加 Adapter 适配器或各种 Middleware 工具。而且现在大部分卖课的教程，大家都是在做各种各样的 Agent 开发教程，这就导致大量的人涌入这个行业，形成了竞争的加剧。

而且，对代码之外的各类 Agent 来说，它们更多的是缺乏一种合适的工具——合适的 CLI 来接入。以及有了对应的 CLI 之后，如何根据对应的数据来训练模型、让模型更好地使用这些 CLI，我认为这类数据也是比较欠缺的。所以就导致了今天的局面：GPT 使用 Computer Use 去模仿人的操作习惯来操作 EDA 或者 UE5 这样的软件，而不是通过 CLI 来操作。

但 Computer Use 是不可持续的：它强依赖于模型的多模态视图能力，所以它要不断截图来验证自己的接过。首先，费用就是一个非常大的问题，因为在企业中，大家大部分的 Codex 除了自己开的 Plan，大部分都是在使用 API，而自己的 API 额度根本经不起这样的消耗。还有看到一些《杀戮尖塔》的AI视图通关视频，以及结合我个人的使用经验来说，它识图的速度是非常非常慢的，就ue5来说根本无法跟一个熟练的 UE5 开发人员相比。

结语

笔者在河畔上上看到越来越多的人想去做 Agent应用开发，我认为这完全是一条错误的道路：未来根本不会存在 Agent 开发这样一个行业。这已经是一个被判死刑的行当。