AI 智能体，业务规模提升百倍的关键

撰文：vas

编译：AididiaoJP，Foresight News

AI 不是魔法，但也没有简单到「搭个 AI 程序、自动搞定一切、坐等收益」的程度。大多数人其实并不清楚 AI 究竟是什么。

而那些真正明白的人（不到 5%）尝试自己去搭建，结果往往失败。智能体会出现「幻觉」、会在任务中途忘记自己做到哪一步、或者在不该调用工具的时候错误调用。演示时它运行完美，一到生产环境就立刻崩溃。

我部署 AI 程序已经一年多了。我的软件职业生涯始于 Meta，但半年前我离职创立了一家公司，专门为企业部署生产可用的 AI 智能体。现在我们年经常性收入已达到 300 万美元，并且还在增长。这不是因为我们比别人聪明，而是因为我们反复试错、失败多次，终于摸清了成功的公式。

以下是我在构建真正可用的智能体过程中学到的一切。无论你是初学者、专家，还是介于两者之间，这些经验都应该适用。

第一课：语境就是一切

这听起来可能特别明显，你或许也早就听说过。但正因为它如此重要，才值得反复强调。很多人以为构建智能体就是把各种工具连起来：选个模型、开放数据库权限、然后你就撒手不管了。这种做法会立刻失败，原因有几个：

智能体不知道什么是重点。它不知道五步之前发生了什么，只能看到当前这一步，然后猜接下来该做什么（而且常常猜错），最后碰运气。

语境，往往是价值百万的智能体与一文不值的智能体之间最根本的差别。你需要重点关注并优化这几个方面：

智能体记得什么：不仅是当前任务，还包括导致现状的完整历史。比如处理发票异常时，智能体需要知道：异常是怎么触发的、原始发票是谁提交的、适用哪条政策、这个供应商上次出问题是怎么处理的。没有这些历史，智能体就是在瞎猜，这比没有智能体还糟。因为如果靠人处理，问题可能早就解决了。这也解释了为什么有人吐槽「AI 真难用」。

信息如何流动：当你有多个智能体，或者一个智能体处理多步流程时，信息必须在各阶段间准确传递，不能丢失、损坏或被误解。负责分类请求的智能体，必须把干净、结构化的语境传给负责解决问题的智能体。如果交接不严谨，下游全乱。这意味着每个环节都要有可验证的结构化输入和输出。一个例子是 Claude Code 里的 /compact 功能，它能在不同 LLM 会话之间传递上下文。

智能体对业务领域的了解：处理法律合同审查的智能体，必须清楚哪些条款关键、风险预估、公司实际政策是什么。你不能只丢给它一堆文档，就指望它自己悟出重点，这是你的责任。而你的责任也包括：用结构化的方式为智能体提供资源，让它真正具备领域知识。

糟糕的语境管理表现为：智能体因为忘记已获得答案而重复调用同一工具；或者因收到错误信息而调用错误工具；又或者做出与前面几步矛盾的决定；甚至每次都把任务当全新的处理，无视以往相似任务中存在的明显模式。

良好的语境管理则让智能体像一位经验丰富的业务专家：它能在不同信息间建立联系，无需你明确告诉它这些信息有什么关系。

语境，是区分「只能演示」的智能体和「真正在生产环境运行并交付成果」的智能体的关键。

第二课：AI 智能体是成果倍增器

错误的看法：「有了它，我们就不用招人了。」

正确的看法：「有了它，三个人就能干以前十五个人的活。」

智能体终将替代部分人力劳动，不承认这一点只是自欺欺人。但积极的一面是：智能体不会取代人类判断，而是消除围绕人类判断产生的各种摩擦，比如查找资料、收集数据、交叉比对、格式整理、任务分发、跟进提醒等等。

举个例子：财务团队依然需要为异常情况做决策，但有了智能体，他们不用再花 70% 的结账周时间去翻找缺失单据，而是能用这 70% 的时间真正解决问题。智能体完成所有基础工作，人类只做最终审批。根据我为客户服务的经验，实际情况是：企业并不会因此裁员。员工的工作内容会转变，从繁琐的手工操作转向更有价值的任务，至少目前如此。当然，长远来看，随着 AI 进一步发展，这种情况可能会改变。

真正从智能体中获益的公司，不是那些只想把人类踢出流程的，而是那些意识到：员工大部分时间花在了「铺垫性工作」上，而不是真正创造价值的部分。

按这个思路设计智能体，你就不用再死磕「准确率」：智能体做它擅长的，人类也专注做人类擅长的。

这也意味着你能更快部署上线。不需要智能体处理所有极端情况，只要它把常见情况处理好，同时把复杂异常转给人类——并附上足够语境，让人能快速解决。至少，现阶段应该这样做。

第三课：记忆与状态管理

智能体如何在一个任务内以及跨任务保存信息，决定了它能否规模化运作。

常见的有三种模式：

独立智能体：单独处理完整工作流，从开始到结束。这种最好搭建，因为所有语境都在一处。但随着流程变长，状态管理会成挑战：智能体必须记住第三步做的决定，等执行到第十步时还要用上。如果语境窗口满了，或者记忆结构不对，后期的决策就会缺乏早期信息支撑，导致出错。

并行智能体：同时处理同一问题的不同部分。速度更快，但引入了协调问题：结果如何合并？如果两个智能体得出矛盾结论怎么办？必须制定清晰的协议来整合信息、解决冲突。通常需要引入一个「裁判」（人或另一个 LLM）来处理冲突或竞态条件。

协作智能体：按顺序交接工作。智能体 A 分类，传给 B 做研究，再传给 C 执行解决方案。这种模式适用于有清晰阶段的工作流，但交接环节最容易出问题。智能体 A 学到的东西，必须以智能体 B 能直接使用的格式传递下去。

大多数人犯的错误是：把这些模式当作「实现方案」来看。实际上，它们是架构决策，直接决定了你的智能体能力边界。

例如你要搭建一个处理销售合同审批的智能体，就必须决定：是让一个智能体全程负责？还是设计一个路由智能体，把任务分发给定价审核、法务审核、高管审批等不同专长的智能体？只有你清楚背后的实际业务流程，希望你最终也能把这些流程教给你的智能体。

怎么选？取决于每个环节的复杂度、阶段间需传递多少语境、以及各环节是需要实时协同还是按序执行。

如果架构选错了，你可能要花几个月去调试一些根本不是 bug 的问题。那其实是你的设计、你要解决的问题以及你的解决方案之间的架构错配。

第四课：主动拦截异常，而非事后报告

做 AI 系统时，很多人的第一反应是：做个仪表板吧，把信息展示出来，让大家看到发生了什么。拜托，真的别再搞仪表板了。

仪表板没什么用。

你的财务团队早知道有票据缺失，销售团队也早知道有些合同卡在法务那里。

智能体应该在问题发生时直接拦截，并转给对应的人去解决，同时提供解决所需的一切信息，立刻执行。

发票来了但文件不全？别只是记到报告里。立刻标记，弄清楚谁该补什么材料，把问题连同完整语境（供应商、金额、适用政策、具体缺什么）转给他。同时阻止这笔交易入账，直到问题解决。这步很关键，否则问题会在组织里到处「泄漏」，你想补救都来不及。

合同审批超过 24 小时没动静？别等到周会再提。自动升级，附上交易详情，让审批人不用到处查系统就能快速决定。要有紧迫感。

供应商没按时完成里程碑？别等谁去发现。自动触发应急预案，在有人意识到问题之前就启动应对流程。

你 AI 智能体的职责是：让问题无法被忽视，且解决起来极其轻松。

要直接暴露问题，而不是通过仪表板间接呈现。

这和大多数公司用 AI 的方式正相反：他们用 AI 来「看见」问题，而你应该用 AI 来「逼着」解决问题，并且要快。等问题解决率接近 100% 了，再考虑要不要做个仪表板看看。

第五课：AI 智能体 vs 通用 SaaS 的经济账

企业不断购买没人用的 SaaS 工具是有原因的。

SaaS 容易采购：有演示、有报价、需求清单上有个勾可以打。有人批了，就觉得事情推进了（虽然往往并非如此）。

买 AI SaaS 最糟的是，它往往就摆在那。它没有融入实际工作流，成了又一个需要登录的系统。你被迫迁移数据，一个月后它只是又多了一个要管理的供应商。12 个月后它被弃用，但你却甩不掉，因为切换成本太高，结果就是「技术债」。

基于你现有系统定制的 AI 智能体就会杜绝此类问题。

它在你已经用的工具里运行，不创造新的工作平台，反而让现有工作更快完成。智能体处理任务，人类只看结果。

真正的成本对比不是「开发费 vs 授权费」，而是更简单的逻辑：

SaaS 积累「技术债」：每买一个工具，就多一个要维护的集成、一个迟早会过时的系统、一个可能被收购 / 转型 / 关闭的供应商。

自建智能体积累「能力」：每次改进都让系统更聪明，每个新工作流都拓展了可能性。投资是复利增长，而不是随时间贬值。

所以我过去一年一直说：通用 AI SaaS 没有未来。行业数据也在印证：多数采购 AI SaaS 的企业在 6 个月内停用，且完全没看到生产力提升。真正从 AI 中获益的，都是那些拥有定制智能体的公司，无论是自研还是找第三方开发的。

这就是为什么早期掌握智能体的公司会拥有长期的结构性优势：他们在建设会越来越强的基础设施。其他人只是在租用迟早要换掉的工具。在这个领域每月都在剧变的时代，每浪费一周，对你的产品路线图和整体业务都是重大损失。

第六课：部署要快

如果你的 AI 智能体项目规划一年才能上线，那已经输了。

计划赶不上变化。你设计的工作流很可能不符合实际工作方式，而你没想到的边缘情况往往最重要。12 个月后 AI 领域可能天翻地覆，你做的可能已是过时的产物。

最多 3 个月，必须进入生产环境。

在这个信息爆炸的时代，真正的能力在于：知道如何有效利用信息，并与之协作而非对抗。要实际干活：处理真实任务、做出真实决策、留下可追溯的记录。

我见过最普遍的问题是：内部开发团队常把本应 3 个月完成的 AI 项目估成 6–12 个月。或者更糟——嘴上说 3 个月，开工后却用各种「意外原因」不断延期。这不全怪他们，AI 领域确实复杂。

所以你需要真正懂 AI 的工程师：他们理解 AI 如何规模化运作、见过真实场景中的问题、清楚 AI 的能力与局限。现在有太多「半桶水」开发者，以为 AI 什么都能做——这离事实太远了。如果你是一名想进入企业级应用 AI 领域的软件工程师，你必须扎实掌握 AI 的实际能力边界。

总结一下

构建可用的智能体，关键在这几点：

语境决定一切：没有好上下文的智能体只是昂贵的随机数生成器。务必做好信息流转、记忆持久化、领域知识嵌入。以前大家笑话「提示词工程师」，现在「上下文工程师」就是它的 2.0 版。

为「增效」设计，而非「替代」：让人做人擅长的事，让智能体清理道路，使人更专注。

架构比模型选择更重要：用独立、并行还是协作智能体，这个决策比选哪个模型关键得多。先把架构搞对。

拦截并解决，而非报告与回顾：仪表板是问题的「坟墓」。要建立能逼着问题被快速解决的系统。

快速上线，持续迭代：最好的智能体是已在生产环境运行并不断改进的那个，而不是还在设计中的那个。（并且要盯紧你的时间表）

其他都是细节。

技术已经就绪，但你可能还没准备好。

搞明白这一点，你就能把业务规模扩大 100 倍。