所有人都在做 Agent，但很多人连 Agent 是什么都没想明白

昨天，我去逛了一圈世界人工智能大会，也就是 WAIC。

今年的会场里，有一个词几乎无处不在：

Agent。

做大模型的在讲 Agent，做企业服务的在讲 Agent，做招聘、营销、医疗、金融、法律、教育的，也都在讲 Agent。

过去两年，大家还在说自己做的是“大模型应用”“AI 助手”“行业 Copilot”。到了今年，不在产品介绍里加上 Agent，好像都不好意思说自己是一家 AI 公司。

但我在现场和一些公司聊下来以后，产生了一个很强烈的感受：

很多人不只是没有做好 Agent，甚至连 Agent 到底是什么东西，都没有真正想明白。

他们会很兴奋地告诉我：

我们做了一个某某 Agent，可以帮你完成某某工作。

于是我接着问：

那我怎么用？

这个问题听起来很简单，但很多人的回答立刻开始变得含糊。

有的说：

我们有一个网页，你登录进去就可以用了。

有的说：

我们给你提供 API，你们系统接一下就行。

还有的说：

我们可以私有化部署，也可以嵌入你们现在的软件。

这些回答本身都没有错。

问题在于，他们经常把“Agent 是什么”和“Agent 怎么交付”混成了同一件事。

好像做了一个网页，网页里面放了一个聊天框，它就是 Agent。

或者在大模型外面包了一层 API，这个 API 就叫 Agent。

甚至有些人会产生一种很奇怪的想象：

我做好了一个 Agent，就像做好了一个 Excel 文件一样，可以直接把这个 Agent 发给你，你拿过去就能用。

但实际上，Agent 从来不是一种固定的软件形态。

它既不天然是一个 APP，也不天然是一个网站、API、函数或者软件模块。

这些都只是它可能呈现出来的外壳。

Agent 不是一种产品形态，而是一种运行方式

先说结论。

我认为，Agent 最准确的定义应该是：

Agent 是一种能够接收目标、观察当前状态、自主决定下一步行动、调用外部工具，并根据行动结果继续调整，直到完成任务或触发终止条件的软件系统。

这里最关键的，不是用了大模型，也不是接了几个工具。

而是四件事：

目标、决策、行动、反馈。

假设我给一个投资尽调 Agent 下达任务：

帮我调查一下这家公司是否值得投资。

一个真正的 Agent，不应该只是把这句话连同几份材料一起塞给大模型，然后生成一篇看起来像模像样的报告。

它应该能够自己推进任务。

比如先拆解问题：

• 这家公司是做什么的？
• 所处行业怎么样？
• 收入和利润是否真实？
• 核心客户是谁？
• 有没有法律风险？
• 创始团队过去做过什么？
• 市场规模和竞争格局如何？
• 目前还缺哪些证据？

然后，它可能去搜索公开资料，查询企业数据库，阅读财报，分析访谈记录，调用估值模型。

如果中途发现收入数据和新闻报道矛盾，它应该继续调查。

如果发现某个关键文件缺失，它应该知道自己暂时不能下结论。

如果某个工具调用失败，它应该更换参数、重新尝试，或者请求人工介入。

整个过程更像这样：

观察当前状态
判断下一步做什么
选择工具并执行
查看执行结果
更新当前状态
再决定下一步做什么

这个循环，才是 Agent 的核心。

因此，Agent 并不是一个神秘的新文件格式，也不是某种独立于现有软件体系之外的新物种。

它本质上仍然是一套软件系统。

只是这套系统过去由程序员提前规定每一步怎么走，现在其中一部分路径选择，开始交给模型动态决定。

网页、APP、API，都只是 Agent 的入口

既然 Agent 是一套系统的运行方式，那么它当然可以被包装成不同的产品形态。

最常见的是网页。

比如一家公司做了一个合同审查 Agent。

用户登录网站，上传合同，点击“开始审查”，过一会儿得到一份报告。

从用户的角度看，它就是一个网站。

但网站只是前端入口。

网页背后可能启动了一个任务队列，Agent 在服务器上读取合同、识别条款、查询法规、对比模板、发现风险，最后再生成结果。

它也可以被包装成一个 APP。

用户在手机里输入任务，后端启动同一套 Agent 系统。

它还可以被包装成 API。

B 公司向 A 公司发送一个请求：

帮我分析这家公司过去三年的经营风险。

A 公司返回一个任务编号。

过几分钟或者几小时后，B 公司再来查询任务状态，最终取得报告。

对 B 公司来说，它只是调用了一个 API。

但在这个 API 背后，可能发生了几十次模型调用、搜索、数据库查询和代码执行。

它也可以被包装成 SDK。

A 公司把代码库交给 B 公司，让 B 公司把 Agent 运行在自己的服务器里，连接自己的数据库，使用自己的模型和权限系统。

它还可以被做成一个 Docker 镜像，部署进企业内网。

甚至可以被包装成一个 MCP Tool，让另一个 Agent 来调用。

所以，当一家公司的产品负责人说：

我们做了一个 Agent。

这句话本身几乎没有提供任何有效信息。

因为我仍然不知道：

• 这是一个网站，还是一个 API？
• 它运行在谁的服务器上？
• 用户把什么任务交给它？
• 它能采取哪些实际行动？
• 数据会不会离开企业？
• 是否支持异步任务？
• 失败以后如何重试？
• 是否有人工审批？
• 谁为最终结果负责？

“我们做了一个 Agent”，就像一家餐厅告诉你：

我们做的是现代化餐饮系统。

听起来很高级，但你仍然不知道它到底卖什么菜，怎么点餐，多少钱，以及能不能吃。

很多所谓 Agent，其实只是工作流

现在行业里还有另一个非常普遍的问题：

把所有带大模型的自动化流程，都叫作 Agent。

例如：

读取文件
提取文字
调用大模型总结
把结果整理成表格
发送邮件

如果这五个步骤是程序员提前写死的，那么它本质上是一个 AI 工作流。

工作流没有任何问题。

事实上，在大量真实的企业场景里，工作流往往比 Agent 更稳定、更便宜，也更容易审计。

但它不是因为接了大模型，就自动变成了 Agent。

工作流的核心是：

程序员提前决定路径。

Agent 的核心则是：

程序员定义目标、工具和边界，模型在运行过程中动态决定路径。

两者并不是非黑即白，中间存在大量混合形态。

比如前半段使用固定流程，到了异常处理环节，再由 Agent 判断应该查询哪份资料、调用哪个工具。

这种混合架构在生产环境里反而可能更加合理。

问题不在于一个产品是不是“纯 Agent”。

问题在于，很多公司一边使用完全固定的流程，一边为了融资、宣传或者赶时髦，强行把工作流包装成 Agent。

最后导致这个词迅速失去意义。

“做了一个 Agent”不等于“别人可以直接拿来用”

我在 WAIC 现场遇到的另一个典型误区，是一些人默认：

只要我们把 Agent 做出来，其他公司就可以直接使用。

但企业软件从来没有这么简单。

假设 A 公司做了一个销售 Agent，B 公司想使用。

这时真正的问题不是：

你有没有 Agent？

而是：

这个 Agent 如何进入 B 公司的业务系统？

如果它要读取客户信息，就要连接 B 公司的 CRM。

如果它要发送邮件，就要获得邮箱权限。

如果它要判断客户是否值得跟进，就需要理解 B 公司的销售规则。

如果它要修改商机阶段，就要接入内部权限体系。

如果它要联系客户，还需要确定哪些动作可以自动执行，哪些必须经过人工批准。

这时，A 公司真正需要交付的，可能是：

• 一个 SaaS 网站
• 一组 API
• 一个 SDK
• 一套私有化部署系统
• 一个 MCP Server
• 一套数据连接器
• 一套权限和审批机制
• 一套日志、监控与审计系统

Agent 只是其中负责“理解任务并动态决策”的一部分。

它不是整个产品，更不是整个交付过程。

一家企业真正购买的，也通常不是一个抽象的 Agent。

企业购买的是某种具体能力：

帮我审查合同。
帮我筛选客户。
帮我处理工单。
帮我调查公司。
帮我分析财务风险。
帮我生成销售线索。

至于这个能力背后用了一个 Agent、十个 Agent，还是一个普通工作流，客户其实并不关心。

客户关心的是：

• 输入什么？
• 输出什么？
• 正确率多少？
• 执行需要多久？
• 能不能接入现有系统？
• 数据是否安全？
• 出错了谁负责？
• 到底能省多少钱？

如果这些问题回答不清楚，那么“Agent”三个字说得再多，也只是技术包装。

判断一个 Agent，别先问它用了什么模型

现在很多人在介绍 Agent 时，最喜欢先说：

我们底层使用了某某大模型。
我们用了多 Agent 架构。
我们支持 RAG、MCP 和长期记忆。
我们构建了行业知识库。

这些当然可以介绍。

但它们都不是最重要的问题。

真正判断一个 Agent 是否成立，我更关心下面几件事。

第一，它能接受什么完整任务？

不是“它能回答什么问题”，而是用户可以把什么工作完整地交给它。

第二，它能采取什么行动？

只能生成一段文字，和能够查询数据库、修改 CRM、运行代码、发送邮件，是完全不同的产品。

第三，执行路径是谁决定的？

如果所有步骤都已经被开发者写死，那它更接近工作流。

如果模型会根据中间结果决定继续搜索、切换工具、调整策略，它才更接近 Agent。

第四，它有没有状态？

它是否知道任务已经做到哪里，哪些信息已经验证，哪些问题还没有解决，哪些工具曾经失败。

第五，失败以后怎么办？

一个演示版系统往往遇到错误就结束。

一个生产级 Agent 必须知道什么时候重试、什么时候换工具、什么时候暂停、什么时候交给人。

第六，权限怎么控制？

如果 Agent 可以发邮件，它可以发给谁？

如果它可以修改数据库，它可以修改哪些字段？

如果它可以付款，付款上限是多少？

如果没有权限、审批、审计和回滚，那么所谓的“自动执行”，很可能只是把风险藏了起来。

第七，别人到底怎么接入？

网页、API、SDK、私有部署、MCP，还是别的形式？

如果一家公司只能反复告诉你“我们做了一个 Agent”，却始终说不清楚别人如何把它接入现有业务，那么这个 Agent 很可能还只是一个 Demo。

Agent 不是产品答案，它只是实现手段

我并不是说 Agent 没有价值。

恰恰相反，我认为 Agent 很可能会成为未来软件系统里非常重要的一层。

过去的软件要求用户自己理解功能。

用户要知道点击哪个按钮，填写哪张表格，选择哪个菜单，才能让软件完成某件事。

Agent 带来的变化，是用户可以直接描述目标：

帮我把最近一个月流失的高价值客户找出来，分析流失原因，再分别制定召回方案。

系统再自己决定需要查哪些数据、运行哪些分析、生成什么内容。

从这个角度看，Agent 确实有可能改变软件的交互方式。

但 Agent 不是产品答案。

它只是实现产品能力的一种手段。

就像数据库不是产品答案，云计算不是产品答案，微服务也不是产品答案。

一家创业公司不会因为用了 PostgreSQL，就自动变成一家优秀公司。

也不会因为把单体系统拆成微服务，就突然获得商业价值。

同样，做了 Agent，也不意味着自动拥有产品、客户和商业模式。

今年大家一窝蜂创业做 Agent，让我想起过去很多技术浪潮。

每当一个新的技术概念出现，行业最先做的往往不是认真理解它，而是先把自己原来的东西重新命名一遍。

聊天机器人改名叫 Agent。

自动化脚本改名叫 Agent。

工作流改名叫 Agent。

搜索加总结也改名叫 Agent。

最后，所有东西都是 Agent，也就等于没有东西是 Agent。

结语

从 WAIC 回来以后，我越来越觉得，今天行业里最缺的并不是更多 Agent。

而是先把几个最基本的问题想明白：

你到底在帮谁完成什么任务？
为什么这个任务需要 Agent，而不是普通工作流？
Agent 能够采取什么行动？
它如何接入客户现有系统？
客户最终购买的究竟是什么能力？

Agent 不是一个 APP，不是一个网站，不是一个 API，也不是一个函数。

它是一套软件系统内部，围绕目标自主判断、调用工具、根据反馈持续执行的机制。

APP、网站、API、SDK、MCP 和私有化部署，只是别人接触这套能力的不同方式。

所以，下一次再有公司告诉你：

我们做了一个 Agent。

先别急着问它用了哪个模型。

你只需要问一句：

那我到底怎么用？

这个问题，通常比任何技术架构图都更能检验，它做出来的到底是一个真正的产品，还是又一个披着 Agent 外衣的演示项目。