生产级AI Agent的真实技术栈：框架只是脚手架

AI Agent 这个词正在被滥用。一个调用工具的函数叫 Agent，一个有记忆的聊天机器人也叫 Agent，一个带循环的脚本还是叫 Agent。这种语义稀释不只是叫法问题，它正在制造真实的工程错误：简单的流水线被过度设计，真正复杂的系统反而欠设计。

本文整理了一位长期在一线构建和观察 AI 系统的工程师的实战判断，聚焦一个被演示视频掩盖的问题——生产环境里的 Agent 到底长什么样。

Agent 的边界在哪里

作者给出的定义很克制：一个 Agent 是拥有「目标」而不只是「指令」的系统。它自己决定下一步做什么，处理失败，并且知道什么时候算完成。其余的都只是包装精美的函数调用。

这个定义可以当作一把标尺：

• 如果系统需要人一步步告诉它怎么做，它是聊天界面，不是 Agent。
• 如果系统能在工具调用失败后换一种方式重试，它开始接近 Agent。
• 如果系统能把目标拆解成子任务并分派出去，这才是真正的 Agent。

评论区常见的一种误判是，团队花几周给本来一个结构化提示就能解决的工作流加上「agentic 编排」。在动手之前先用这把标尺量一下，往往能省下大量返工。

生产环境的真实面貌：窄而深

从实际交付的团队来看，绝大多数 Agent 部署都是窄范围的。客服工单分流、文档抽取、特定代码库的代码审查——它们不是通用推理引擎，而是带有智能决策层的目的性流水线。

效果好和效果差的团队，分水岭不在模型选型上。

拿到好结果的团队在死磕三件事：

1. 工具设计：Agent 究竟能调用什么，接口是否干净。工具签名模糊是失败的头号来源。
2. 失败处理：工具返回空结果或不相关结果时，系统如何降级、重试或转人工。
3. 可观测性：能否追踪 Agent 为什么做出某个决策，而不只是看到它做了什么。

拿到坏结果的团队则有一个共同模式：把 GPT-4 换成最新的前沿模型，其他什么都不改，然后期待行为发生变化。模型升级不会修复架构缺陷。

可观测性（Observability） 在 Agent 语境下不只是打日志。传统服务的可观测性依赖指标、日志、链路追踪三件套，而 Agent 的难点在于决策过程本身不可直接观测：同一个输入可能走出不同路径，失败往往表现为「工具调用成功但结果无用」。面向 Agent 的实践通常需要记录完整的轨迹（trace）——每次模型调用、工具入参出参、重试与降级、以及中途产生的中间推理，并把它们按会话或任务串起来可回放。有了轨迹，团队才能回答「它为什么这么选」而不只是「它做了什么」，才能把失败样本转化为工具签名或提示词的改进项。缺少这一层，调优基本靠猜，模型升级也无法验证是否真的改善。

框架战争是干扰项

LangChain、LangGraph、CrewAI、AutoGen、Semantic Kernel——每个月都有新框架出现，每个月都有人写文章宣告旧框架已死。作者的观点很直接：框架的重要性远低于模式。

跨框架反复验证有效的几个模式：

• 先规划后执行：用一个推理步骤产出计划，用另一个独立步骤执行计划，不要混在一起。
• 检索与推理分离：取回上下文和使用上下文是两件事，把它们揉在一起的系统容易混乱。
• 显式交接：Agent 之间传递工作时，交接应当是结构化且被记录的，而不是一段塞进提示词的字符串。

作者称自己在三个不同框架里重建过同一套架构，结果大同小异。框架是脚手架，架构才是建筑本身。

先规划后执行（Plan-and-Execute） 与常见的 ReAct 式边想边做不同：系统先用一次推理产出显式计划，再由独立的执行步骤逐步完成并根据结果修正计划。分离的价值在于两点：计划是可检视、可缓存、可复用的中间产物，便于人工干预与审计；执行阶段可以针对单步做重试、并行或替换工具，而不必重跑整条推理链。代价是计划的刚性——环境变化快时，静态计划容易过时，因此实践中常与重规划（replanning）结合。它与「检索与推理分离」「显式交接」同属一类思想：把不同性质的工作拆成边界清晰的阶段，而不是全部压进一段提示词里让模型自由发挥。

检索的老问题：分块边界

RAG 已经是标配，但教程很少讲透一个问题：分块边界往往是错的。

把文档切块并嵌入时，你对「哪些上下文应该在一起」做了假设，而这些假设经常不成立。一个离开前文就读不懂的段落被单独检索出来，模型就会自行脑补缺失的上下文，幻觉由此产生。

改进方向包括重叠窗口、语义分块、父文档检索。但真正的修复是重新思考存储的对象——有时候该存的不是原始文本，而是信息的结构化表示。

一个实用的排查口诀：如果 RAG 返回的结果技术上正确但语境上无用，问题几乎一定出在分块或元数据上，而不是嵌入模型。换嵌入模型通常是浪费预算。

父文档检索（Parent Document Retrieval） 是一种针对分块边界问题设计的检索模式：索引时把文档切成小块用于嵌入和相似度匹配，但命中后返回的不是这个小块本身，而是它所属的更大单元（父文档或父段落）。这样既保证了向量检索的粒度足够细、召回准确，又让生成阶段拿到完整的上下文，减少模型因缺前文而脑补。常见实现有两类：一是维护小块到父块 ID 的映射，命中后按 ID 回取；二是用句子窗口检索，命中某个句子后向前后各扩展若干句。它不能自动修复语义割裂的原始结构，但对「段落离开前文读不懂」这类问题效果明显，代价是上下文长度增加和存储多一层索引。

值得关注但需独立判断的行业动态

原文在讨论技术栈的同时，还顺手引述了几条行业新闻，这些属于单一来源的观察，读者应自行核实：Anthropic 宣布将 5% 的股份投入「公共利益基金」；迪士尼同意接收 Character.AI 的大部分员工（属竞标程序中的「马前卒」报价，仍可能有其他公司出价）；Meta 删除了引发爬虫与 AI 训练担忧的相关条款措辞，其发言人坚称爬取方式未变。

这些动态与 Agent 工程没有直接因果关系，但反映出模型厂商与内容生态之间的张力正在加剧，而这会间接影响数据获取与合规成本。

接下来拼的是什么

模型会继续变强，上下文窗口会继续扩大，单 token 成本会继续下降。这些都不改变核心工程挑战：构建一个在无人盯着时也能正确行事的系统。

真正值得投入的是治理、可观测性和可靠的工具体系，而不是刷榜。作者判断，两年后真正稀缺的工程师，是那些能构建出其他工程师可维护、可信任的 AI 系统的人——这更接近系统设计能力，而不是微调或提示词工程。