资深AI工程师谈Agent热潮：定义、生产实践与真实挑战

被稀释的"Agent"概念正在引发工程灾难

一位长期在AI一线工作的工程师在RSS源中分享了他的观察：他花大量时间阅读论文、动手构建系统、与真正在交付产品的工程师交流，发现演示Demo和生产系统之间存在一个"没人完全诚实面对"的鸿沟。

问题的核心在于"Agent"一词的滥用。一个调用工具的函数？叫Agent。一个有记忆的聊天机器人？叫Agent。一个带循环的脚本？也叫Agent。这种语义稀释"不只是措辞问题，它正在导致真实的工程错误"。

当团队对要构建的东西没有精确定义时，结果就是：对简单流水线过度工程化，对真正复杂的系统却又工程不足。他见过团队花费数周为"一个结构良好的单次提示就足够"的工作流添加"agentic"编排层。

他反复回归的定义是：Agent是一个拥有目标而不只是指令的系统。它自己决定下一步做什么，处理失败，并且知道何时完成。 其他所有东西，不过是一个花哨的函数调用。

他用一个简洁的层级来判断：如果系统需要人类告诉它每一步，那它只是聊天界面；如果系统能从工具调用失败中恢复并尝试不同方法，那才算入门；如果系统能将目标分解为子任务并委派执行，那才是真正的Agent。

生产环境中的真实图景

据他从所关注和交谈的团队了解到的诚实情况：大多数真实Agent部署都是窄范围的。它们把一件事做好——客服分诊、文档提取、特定代码库上的代码审查。它们不是通用推理引擎，而是"在决策层加入了一些智能的专用流水线"。

取得好结果的团队并不是在追逐最新模型发布。他们在死磕三件事：

• 工具设计：Agent实际能调用什么，接口有多干净
• 失败处理：当工具返回无用的结果时会发生什么
• 可观测性：你能否精确追踪Agent为什么做出某个决策

而取得糟糕结果的团队，恰恰是那些"把GPT-4换成最新前沿模型，却期望行为改变而不做其他任何调整"的团队。

他也注意到近期一些值得关注的行业动态：Cal AI的病毒式成功背后是一支小型网红军队的付费推广，该公司两年内创造了超过3000万美元收入并被MyFitnessPal收购；Meta与Apple合作推出了可在Apple Silicon上本地运行的开源权重模型Muse Spark Open；Amazon设备主管Panos Panay在TechCrunch Disrupt上描述了一个环境AI设备在后台工作、主动预测用户需求的未来——届时应用可能不再被需要。

可观测性（Observability） 在Agent语境中比传统后端监控要求更高。传统系统只需记录请求、错误和延迟；Agent系统还需要记录完整的决策轨迹：每一步调用了哪个工具、传入什么参数、返回什么结果、模型为何选择这条路径、失败后是否重试以及重试策略。

这通常通过链路追踪（tracing） 实现——把一次Agent运行拆成一棵调用树，每个节点包含输入、输出、耗时和元数据。没有这层可观测性，团队只能看到最终答案对错，无法定位是哪一步推理或工具调用出了问题，调试就退化为猜测。

此外，工具设计之所以关键，是因为模型只能看到工具的名称、描述和参数schema，接口模糊会直接导致调用错误。把工具设计成窄而明确的函数（如get_order_status(order_id)），比一个参数众多的万能工具更容易被模型正确使用。

框架之争是一场干扰

LangChain、LangGraph、CrewAI、AutoGen、Semantic Kernel——每个月都有新框架出现，有人写文章说旧的已死。

他的核心观点是：框架不如模式重要。 无论用什么框架都持续有效的模式包括：

• 先规划再执行：用一个推理步骤产生计划，用另一个独立执行步骤遵循计划，不要混在一起
• 检索与推理分离：获取上下文和使用上下文是两份不同的工作，混为一谈的系统会陷入混乱
• 显式交接：当Agent之间传递工作时，交接应该是结构化的、被记录日志的，而不是通过提示词传个字符串

他提到自己"用三种不同框架重建了相同的架构，结果每次都相似"。框架是脚手架，架构才是建筑本身。

显式交接（Explicit Handoff） 指的是Agent之间或Agent与人类之间传递工作时，用结构化数据（如JSON对象，包含任务、上下文、约束、预期输出格式）而不是自然语言字符串来交接。用字符串交接时，接收方需要重新解析意图，容易丢失字段、误解范围，且难以在日志中比对。

结构化交接还能让每个交接点成为可测试的边界：可以单独验证交接数据的正确性，而不必端到端重跑整个链路。这与先规划再执行、检索与推理分离一样，属于不依赖具体框架的架构模式——它们把系统的关注点分开，让每一层都能被单独调试和替换。

这也解释了为什么作者说“用三种不同框架重建相同架构，结果每次都相似”：框架差异主要体现在语法和内置工具上，而架构模式决定了系统在失败时的行为。

检索问题：没人真正解决的难题

RAG已成为标配，几乎所有涉及专有数据的生产AI系统都在用某种形式的RAG。但教程没有讲清楚一个核心问题：分块边界是错的。

当把文档切分成块并嵌入时，你是在对"哪些上下文片段应该在一起"做假设。这些假设经常是错的。一个只有在结合前一段才说得通的段落被孤立检索，模型就会幻觉出缺失的上下文。

更好的分块策略有帮助——重叠窗口、语义分块、父文档检索。但真正的修复在于重新思考存储的内容本身：有时候应该存不是原始文本，而是信息的结构化表示。

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

RAG（Retrieval-Augmented Generation，检索增强生成） 是当前生产级AI系统处理专有数据的标准范式：它不把全部知识塞进模型权重，而是在推理时先从外部知识库检索相关片段，再把这些片段作为上下文喂给模型生成答案。典型流水线包括：文档切分（chunking）、嵌入（embedding）存入向量数据库、按查询做相似度检索、将top-k片段拼入提示词。

RAG的价值在于知识可更新、可溯源、成本可控，不必为每份新数据重训模型。但它也把传统软件工程中的检索质量问题引入了AI系统——检索不到正确上下文时，模型只能靠参数记忆硬撑，从而产生幻觉。

文中提到的语义分块指按语义边界（段落、小节、主题漂移点）切分而非固定字符数；父文档检索（Parent Document Retrieval）则是索引时用小块保证检索精度、返回时用其所属大块保证上下文完整，二者都是为了缓解分块边界假设错误带来的问题。

未来走向：值得解决的问题

模型会持续变好，上下文窗口会持续扩大，每token成本会持续下降。但这些都不会改变根本的工程挑战：构建在你没有盯着时也能正确行事的可信系统。

他认为这才是值得解决的问题——治理、可观测性和可靠的工具有效使用，而不是追逐基准测试分数。

两年后真正重要的工程师，是那些能构建其他工程师可以维护和信任的AI系统的人。这是一种不同于微调或提示词工程的技能组合，它更接近系统设计，而非模型研究。

正如他所言：这个领域有趣的对话不在主题演讲里，而在那些人们真正诚实地分享什么有效的讨论串中。

背景补充

窄范围Agent（Narrow Agent） 是与“通用推理引擎”相对的概念：它只在一个受限的领域内做决策，输入输出边界清晰，失败模式可枚举。客服分诊只判断工单该路由到哪个团队，文档提取只从固定版式中抽取字段，代码审查只针对特定代码库的常见问题模式。

窄范围的价值在于可评估：因为任务定义清晰，团队可以构建测试集、量化准确率、定位错误来源。而追求通用Agent往往导致无法定义“成功”，也就无法迭代。文中“对简单流水线过度工程化、对真正复杂的系统却又工程不足”的失衡，正是没有先明确范围就开始选框架的结果。