@恩宇-关于AI Agent 落地的思考

挺有价值的一段思考，摘录过来保存一下。

快 2027 年了，我越来越觉得，单纯会开发 Agent，真的不算什么竞争力了。

现在 AI 圈有个特别割裂的现象。

一边是大家天天讨论最新的 Agent 框架、MCP、Skills、多智能体协作，恨不得让 AI 一个人干完一家公司的活。

另一边是你真正走进企业，发现很多项目连最基本的稳定性、权限管理、异常处理都没有解决。

卧槽，这种差距真的太明显了。

最近我自己也一直在折腾企业知识库、GEO 自动化、视频生产工作流，包括一些企业内部的软件系统。

做得越多，我反而越觉得：让 Agent 跑起来越来越容易了，让 Agent 真正跑进企业的业务流程里，才是最难的。

以前觉得接几个 API、调用几个工具、配置一套 Workflow，能把任务自动执行完，就算做出来一个挺不错的 AI 应用了。

但实际接触企业需求之后才发现，根本不是这么回事。

客户不关心你用了多少个 Agent，也不关心你调用的是 LangGraph、Dify 还是 Coze。

他只关心几个问题：原来三个人做的事情，现在能不能一个人完成？原来一天才能处理完的工作，现在能不能缩短到半小时？系统出错了怎么办？客户数据会不会泄露？后面谁来维护？

你技术架构画得再牛逼，业务价值交付不出来，在客户眼里可能就是一个高级玩具。

而且我发现，Agent 开发正在越来越接近传统的软件工程。

尤其是 RAG，很多人以为做知识库就是上传几个 PDF，调用 Embedding，往向量数据库里一存，再接个大模型就完事了。

真正做起来才知道，麻烦的东西全在后面。

文档更新了怎么办？不同版本的内容发生冲突怎么办？员工能不能查到自己没有权限看的文件？检索出来的证据不准确怎么办？模型开始胡说八道怎么办？

这些问题你不解决，模型再聪明也没用。

当然，不是所有 Agent 都需要 RAG，但只要涉及大量企业内部知识和数据，检索质量、权限控制和证据溯源就可能直接决定整个系统能不能用。

还有一点，我觉得现在特别多人忽略了。

AI 能帮你把代码写出来，不代表你就不需要懂软件工程了。

恰恰相反，以前你可能要花很多时间去写 Python、Java、SQL，现在 Codex 能帮你生成大量代码。

但系统怎么部署、接口怎么设计、任务失败怎么重试、数据怎么存储、并发怎么处理、日志怎么记录、线上怎么监控，这些工程责任不会因为 AI 会写代码就消失。

甚至因为代码生成速度太快了，系统质量的控制反而变得更加重要。

还有 Evals，我越来越觉得，做 AI 应用最忌讳的一件事，就是靠感觉验收。

今天改了几句 Prompt，问了五个问题，发现回答不错，就觉得自己优化成功了。

但真正到企业里，几百个员工、几千次调用、几十种业务场景，模型只要在关键任务上出现一次严重错误，就可能影响整个业务。

所以你必须知道任务成功率是多少、检索命中率怎么样、Tool 调用失败了多少次、每次任务花多少钱、哪些场景必须人工接管。

没有这些东西，所谓的优化，很多时候就是自己感动自己。

我现在甚至觉得，未来 AI 应用工程师之间最大的差距，可能不是谁会用更多的框架，而是谁能真正理解一个企业的业务，把需求拆解清楚，再用合适的技术把它稳定地实现出来。

这也是我为什么越来越关注 FDE 这个方向。

它不是让你坐在电脑前天天研究最新的模型，而是让你真正走进企业，弄清楚客户到底有什么问题，判断哪些值得用 AI 解决，再把系统交付出去。

当然，我自己也还在补这些工程能力，离真正成熟的企业级交付还有距离。

但至少方向越来越清晰了，AI 时代，会调用模型的人会越来越多，会开发 Agent 的人也会越来越多。

真正稀缺的，不是能够把 Demo 做得多么炫酷的人，而是能够对结果负责、对业务负责、对交付负责的人。

说到底，企业买的从来不是 Agent，企业买的是效率，是成本下降，是业务增长，是确定性。

谁能把这些东西真正交付出来，谁才有资格拿到下一阶段 AI 应用市场的钱。

会搭 Agent，只是入场券。能把 Agent 做成真正可用、可维护、可规模化的业务系统，才是竞争力。

原文：https://x.com/uping123zzz/status/2112474636076343714?s=46