我花了大量时间在 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)。人工智能编程革命有一个问题：它很贵。Claude Code 是 Anthropic 的基于终端的 AI 代理，可以编写、调试和部署代码...

值得阅读： 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 系统的工程师。这是一种不同于微调或提示工程的技能。

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

如果这些内容与你正在构建的东西产生共鸣，或者你有完全不同的看法，我希望听到你的声音。在评论区分享你的经验。这个领域有趣的对话不在主题演讲中——而在人们真正坦诚讨论什么有效的地方。