我在 AI 领域投入了大量时间——阅读论文、构建产品、与真正从事交付工作的工程师交流。我发现演示效果与生产系统实际表现之间存在巨大差距，而没有人对此完全坦诚。

以下是我对当前实际情况的真实看法。

谈论 AI 代理的方式存在问题

现在每个人都在把所有东西都称为「代理」。一个调用工具的函数？代理。一个带记忆的聊天机器人？代理。一个带循环的脚本？代理。

这种概念稀释不只是语义问题。它正在导致真正的工程错误。

当你对正在构建的东西没有精确定义时，你最终会过度设计简单的流水线，而对真正复杂的系统设计不足。我见过团队花费数周时间为本可以用单个结构化提示就能解决的工作流添加「代理式」编排。

这是我一直使用的定义：代理是一个有目标而非只有指令的系统。它决定下一步做什么。它处理失败。它知道什么时候完成。

其他一切都只是花哨的函数调用。

🟢 如果你的系统需要人类告诉它每一步，那它不是代理。它只是一个聊天界面。

🔵 如果你的系统能够从失败的工具调用中恢复并尝试不同的方法，那你已经有所进展。

✅ 如果你的系统能够将目标分解为子任务并委托执行，那才是真正的代理。

生产环境中的实际情况

我关注和交流的团队给出的真实情况：

大多数真实的代理部署都是狭窄的。它们把一件事做好。客户支持分流。文档提取。特定代码库的代码审查。它们不是通用推理引擎。它们是决策层带有一定智能的专用流水线。

获得良好结果的团队并没有追逐最新的模型发布。他们专注于：

☑️ 工具设计——代理实际可以调用什么，以及接口有多简洁

☑️ 失败处理——当工具返回无用结果时会发生什么

☑️ 可观测性——你能否准确追踪代理做出该决策的原因

获得糟糕结果的团队则是那些把 GPT-4 换成最新前沿模型，却指望在不改变其他任何东西的情况下获得不同行为。

最近频繁出现的内容：Google 25 年来首次重新设计搜索框——其重要性超乎你的想象。（VentureBeat AI）。25 年来，Google 搜索框一直是计算领域最具辨识度的界面之一：一个白色细长矩形，一个闪烁的光标，输入几个词，然后出现一个列表……

值得一读：https://venturebeat.com/technology/google-just-redesigned-the-search-box-for-the-first-time-in-25-years-heres-why-it-matters-more-than-you-think

最近频繁出现的内容：Railway 获得 1 亿美元融资，用 AI 原生云基础设施挑战 AWS（VentureBeat AI）。Railway 是一家旧金山云平台，已悄然积累了 200 万开发者且未花费一分钱营销，本周四宣布完成 1 亿美元融资……

值得一读：https://venturebeat.com/infrastructure/railway-secures-usd100-million-to-challenge-aws-with-ai-native-cloud

最近频繁出现的内容：Claude Code 每月最高花费 200 美元，Goose 免费就能做同样的事。（VentureBeat AI）。人工智能编码革命有一个问题：它很贵。Anthropic 的终端 AI 代理 Claude Code 可以编写、调试和部署代码……

值得一读：https://venturebeat.com/infrastructure/claude-code-costs-up-to-usd200-a-month-goose-does-the-same-thing-for-free

框架之争是干扰

LangChain。LangGraph。CrewAI。AutoGen。Semantic Kernel。每个月都有新框架出现，有人撰文宣称旧框架已死。

我的真实看法是：框架的重要性不如模式。

无论使用哪个框架都有效的模式：

✔️ 先规划后执行。有一个推理步骤生成计划，另一个独立的执行步骤来遵循它。不要把两者混在一起。

✔️ 将检索与推理分离。获取上下文和使用上下文是不同的任务。混淆这两者的系统会陷入混乱。

✔️ 明确的交接。当一个代理将工作传递给另一个代理时，交接应该是结构化且可记录的，而不是通过提示传递字符串。

我曾在三个不同的框架中重建相同的架构，每次结果都相似。框架只是脚手架。架构才是建筑本身。

尚未解决的检索问题

RAG 现在已是标准做法。几乎所有涉及专有数据的生产 AI 系统都使用了某种形式的 RAG。但教程中没有很好地涵盖一个问题。

分块边界是错误的。

当你将文档拆分为块并嵌入时，你是在对哪些上下文片段应该放在一起做出假设。这些假设往往是错误的。只有在看前一段才说得通的段落被单独检索出来，模型就会幻觉出缺失的上下文。

🟢 更好的分块策略会有帮助。重叠窗口、语义分块、父文档检索。

🔵 但真正的解决办法是重新思考你存储的内容。有时应该存储的不是原始文本，而是信息的结构化表示。

✅ 如果你的 RAG 流水线返回技术正确但上下文无用的结果，问题几乎肯定出在分块或元数据上，而不是嵌入模型。

我认为这一切的发展方向

模型会持续变好。上下文窗口会持续扩大。每 token 的成本会持续下降。

这些都不会改变根本的工程挑战：构建在你不监控时也能可靠正确运行的系统。

这才是值得解决的问题。治理、可观测性和可靠的工具使用，而不是追逐基准。

两年后重要的工程师是那些能构建其他工程师可以维护和信任的 AI 系统的人。这与微调或提示工程是不同的技能组合。

它更接近系统设计，而不是模型研究。

如果这些观点与你正在构建的内容产生共鸣，或者你有完全不同的看法，我很想听到。欢迎在评论区分享你的经验。这个领域有趣的讨论不在主题演讲中——而在人们真正坦诚分享有效经验的线程里。