Agent技术栈全景图：五层结构拆解与选型避坑指南

做 Agent 相关开发这一年多我最大的感受是Agent 技术栈的变化速度比传统后端技术栈要快一个量级。今天还在刷屏的编排框架下个月可能就被新的范式盖过去昨天大家还在聊单 Agent 怎么调 Prompt今天讨论的已经是多 Agent 协作、工具协议、记忆分层。也正因为这样很多刚入坑的人学得很累——每天刷到的新工具、新概念像流水一样但始终找不到一张能让自己安心的全景图。所以我一直建议别急着追新先把 Agent 技术栈从“工具名单”还原成“分层结构”搞清楚每一层到底解决什么问题、层与层之间怎么衔接再回头去看工具时每一个名字都能放回自己的位置。这篇文章我想把这张全景图完整拆开来讲。不只会画分层的骨架还会把每一层的核心选型逻辑、常见误区和实操经验填进去。适合两类人看一类是准备从零搭一个 Agent 但不知道从哪儿入手的开发者另一类是已经接了一些框架和模型但项目总在“能跑”和“跑不稳”之间反复横跳的人。看完之后你至少能回答一个问题我的 Agent 出了 Bug问题出在技术栈的哪一层。1. 先看分层再看工具Agent技术栈的本质是一条任务流水线很多 Agent 项目做不下去不是模型不够强也不是工具不够多而是从一开始就没有建立分层意识。大家习惯了把框架当作“Agent 本体”以为选了一个热门框架就等于选好了技术栈结果后续的所有问题都被塞进同一个黑盒里调试变成猜谜。其实 Agent 技术栈的结构没有标准答案但骨架相对稳定。任何一个 Agent无论它是客服、编程助手还是数据分析机器人实际执行路径都可以抽象成一条流水线接收输入模型理解规划决策调用工具生成输出。技术栈里的每一层都是为这条流水线上的某个环节服务的。1.1 为什么很多项目死在“没有分层意识”我见过不少团队把所有逻辑都往 Prompt 里堆系统指令写了一大段历史会话原文塞进去检索回来的文档片段也拼在后面工具调用结果再追加一段。结果模型输出越来越飘一会儿重复用户问题一会儿答非所问。这类问题排查起来特别痛苦因为你根本不知道是模型理解偏了还是参考资料把模型带偏了还是工具返回的结果格式不对。如果在设计阶段就按层切分定位会快很多输出异常先看模型层上下文混乱先看记忆层工具没生效先看工具层。这种隔离能力是分层最大的好处之一。另一个好处是替换成本可控。今天你用某套开源编排框架明天想换成可视化工作流平台只要记忆层和工具层的对外接口不变替换范围就被限制在单层内部不会牵一发而动全身。1.2 五层结构全景图我把 Agent 技术栈粗略拆成五层从下往上分别是模型层、记忆层、工具层、编排层、交互与可观测层。它们之间有依赖关系但不严格串行实际项目中常做交叉组合。分层核心职责常见实现形态交互与可观测层用户入口、日志追踪、效果评测聊天页面、API 服务、Trace 系统编排层任务拆解、流程控制、多智能体协作各类编排框架与工作流平台工具层外部系统调用、Function Calling、插件化服务工具网关、统一工具协议记忆层短期上下文、长期记忆、外部知识检索向量库、摘要库、数据库模型层语言理解、内容生成、工具调用决策各类大模型 API 或微调模型模型层在最底下因为所有 Agent 的智能上限首先由它决定。记忆层负责让模型“记得住”和“查得到”工具层让模型“做得到”编排层决定“怎么做”交互与可观测层保证“能上线”。这五层中大多数项目最大的投入其实不在模型而在记忆、工具和编排上。1.3 分层之后再看新工具就不会慌刚入坑的人遇到一个新框架第一反应是“我是不是应该赶紧迁移过去”。我的建议是反过来先问它替代的是哪一层。如果它只是某层的另一种实现而当前实现没有给你带来不可忍受的痛点那就不急着换如果它在某层引入了新的机制比如更好的状态管理、更完善的记忆方案那也要先在隔离环境里验证再考虑搬迁。分层思维还会帮你识别伪需求。比如有些团队一上来就想做“完全自主探索型 Agent”让模型自己规划每一步。这种设计听起来很酷但在大部分业务场景里流程是相对确定的反而应该用工作流把步骤固定下来。把这个问题想清楚技术栈的选择范围会立刻缩小一半。2. 底座模型选型三个硬指标比跑分更值得关注模型层是 Agent 技术栈的地基但它也是最容易被“跑分误导”的一层。很多人在选模型时只看综合榜单和通用常识而忽略了 Agent 场景真正依赖的三项底层能力指令遵循、工具调用、长上下文处理。这三项能力在通用对话里不一定显眼但在 Agent 的复杂链路里任何一个短板都会被放大。2.1 指令遵循能力决定 Agent 能不能“听人话”所谓指令遵循指的是模型能否理解并执行你给定的结构化指令而不是自由发挥。比如你让一个查询类 Agent 严格按三步执行先识别实体再检索资料最后给出带来源的结论。指令遵循强的模型会按部就班弱的模型可能会跳步甚至把“识别实体”当成一个回答环节直接输出导致整个流程错乱。有一个非常典型的翻车场景用户问“明天上海适合出门吗”如果模型不知道今天的日期、不能主动调起天气工具、也没有结合出行建议的指令它可能会凭训练知识瞎猜一个答案。这种问题在评测通用问答时不会被发现但在 Agent 任务里几乎必然出现。所以我在选模型时一定会构造一批带明确流程要求的用例去做指令遵循测试而不是只看印象。2.2 工具调用能力Agent 能不能“动手做事”的关键工具调用是模型层的核心能力之一也是 Agent 技术栈跟普通 Chatbot 最大的区别。模型需要判断什么时候该调用工具、调用哪个工具、传什么参数然后返回结构化的调用请求由外部系统真正执行。一个标准工具调用的返回结果大致长这样{ name: search_weather, arguments: { city: 上海, date: 明天 } }这段 JSON 不是模型生成的最终回答而是“模型想要调用工具的意图”。拿到它之后程序才会真正去查天气把结果带回给模型继续生成回答。如果模型在这步不稳定Agent 的整个链路就会断掉。所以我测试模型时有个习惯把工具描述和期望参数写成固定用例同一个问题跑十次统计工具调用成功率和参数命中率低于我心理预期的模型直接不进入下一轮评估。2.3 长上下文、成本与响应速度的三角权衡Agent 的每一次回答往往都要带上历史摘要、检索片段、工具结果这些内容叠在一起很容易超过上下文窗口。长上下文模型确实能减少一部分 RAG 开发量但代价是更高的成本和更长的响应时间。我的经验是不要试图让模型“全记住”。哪怕是支持超长上下文的模型在 Agent 链路里也不适合无限塞数据因为模型对中段内容的注意力会衰减而且每次调用都在烧钱。实践中更推荐用摘要机制把历史对话压成几百个 token 的要点检索结果只保留最相关的 Top 5。这样上下文短、响应快、成本低还更容易稳定。2.4 模型选型的最小验证清单在正式动工之前我会做一个低成本验证流程固定下来大概是这样的挑 5 到 10 个最真实的用户问题覆盖正常提问、歧义提问、缺参数提问。把每个问题期望的行为写清楚包括要不要调用工具、要调用哪个工具、最终回答的格式。用候选模型各跑 20 遍统计指令遵循率、工具调用成功率和答案格式合规率。记录平均响应时间和单次成本结合预算做取舍。另外有一点很重要不要一上来就自建模型。Agent 技术栈的演化速度决定了底座模型本身也在快速迭代自建模型的成本非常高而收益未必能跑赢直接用成熟 API。更合理的策略是把模型层设计成可替换的Prompt 和工具尽量与具体模型解耦这样以后更好的模型出来你只需要切换底座而不是推倒重来。3. 记忆与上下文工程Agent“忘事”的根因大多藏在这一层我在很多 Agent 项目里排查“答非所问”“前后矛盾”时发现问题往往不在模型而在记忆层。记忆不是简单地把对话历史存下来它需要区分不同类型并且用不同的策略管理。项目越做越复杂记忆层的设计就越关键。3.1 三种记忆要分开别混在一个变量里我把 Agent 的记忆粗略分成三类。第一类是工作记忆对应当前会话里模型正在处理的上下文通常直接放在 Prompt 里。第二类是长期记忆对应跨会话保存的用户偏好、历史结论、知识摘要通常放在向量库或摘要库中。第三类是事实记忆对应业务系统中的真实数据比如订单状态、库存数量这些不应该让模型靠猜而是通过工具实时查询。不少项目的问题就在于把三类记忆混在一起。比如把几周前的对话原文也塞进当前 Prompt模型看到一堆“过期”信息之后自然就答错了。正确的做法是让每一类记忆各司其职长期记忆做摘要和查询事实记忆靠工具获取工作记忆只保留当下这次回答真正需要的片段。3.2 向量库只是记忆的一种实现不是银弹提到记忆层很多人第一反应是向量库。但向量库解决的问题只是“相似语义召回”它不等于记忆本身。常见的误区有两个一是把所有文档无脑切片、向量化之后就丢进去二是只依赖向量相似度做检索完全不考虑关键词匹配和排序优化。以知识库问答为例按固定 500 字硬切会让一个完整的问题和答案被拆到两个片段里导致检索时召回不完整。更合理的做法是按语义单位切FAQ 类型以“一问一答”作为一个最小单元产品手册按章节和标题切表格单独处理并保留来源、时间、分类等元数据方便后续过滤。同时在检索策略上我不建议只用向量召回。更稳的方案是混合检索向量召回 Top 20关键词召回 Top 10然后通过重排模型或者规则融合最终只取 Top 3 到 5 个片段喂给模型。这样既能抓住语义相近的表达也不会漏掉精确匹配的关键词。3.3 上下文组装顺序比想象中更重要同样一堆信息放在上下文里的顺序不同效果可能差别很大。这跟模型注意力机制有关模型对越靠后的内容往往越敏感而对中间大段内容容易“视而不见”。我常用的组装模板是这样的系统指令与安全边界告诉模型它是谁、能做什么、不能做什么。长期记忆摘要比如用户的历史偏好和之前达成的结论。本次检索到的知识片段按相关度排序。最近对话的压缩摘要保留事件脉络而不是逐字粘贴。当前用户问题放在最末尾确保模型注意力聚焦在最新任务上。这套顺序我调过很多次比较稳定。尤其是“当前问题放最后”这条很多新手实现时会把用户问题放在最早结果模型越往后越偏最后的回答往往丢掉了用户真正的诉求。3.4 三个容易忽略的翻车细节时间依赖问题是我踩过最多的一个坑。模型自身并不知道当前日期如果 Agent 涉及“今天”“本周”“最近一个月”这类时间判断必须在系统指令里注入当前日期。另一个问题是来源引用检索片段最好带编号模型在回答时能标注“根据资料 2 的内容”这样既增强可信度也方便用户复查。还有一个是清理机制长时间运行的会话不可能一直叠上下文超过一定轮数后要把旧内容做成摘要只保留摘要和新一轮对话防止上下文窗口被慢慢耗干。4. 编排层四种框架风格和一套选型判断逻辑编排层是整个 Agent 技术栈里最热闹、也最容易让人眼花缭乱的地方。市面上有数不清的框架和平台每个都说自己能解决 Agent 编排问题。但仔细观察会发现它们底层只有四种风格每种风格适合不同的场景。把风格认清选型就不会太纠结。4.1 编排到底在编排什么编排层实际做三件事控制流、提示词组装、工具挂载。控制流解决的是 Agent 下一步该做什么是按顺序执行还是分支选择是循环重试还是跳到结束提示词组装决定模型每次收到什么样的上下文工具挂载则决定模型在什么条件下能调用什么工具。换句话说框架不是“写好了 Agent”而是帮你管理 Agent 执行过程中的状态和流程。4.2 四种常见框架风格对比框架风格适合场景优点潜在问题代码优先编排型复杂业务逻辑、精细控制灵活度高状态管理清晰学习成本高迭代速度慢可视化工流型快速迭代、运营人员参与上手快流程直观复杂逻辑容易受限自主探索型原型验证、开放任务演示效果好路径灵活生产环境不稳定成本不可控多智能体协作型复杂任务拆解、多人协同角色分工清晰适合专项任务链路长调试复杂度高代码优先型适合团队里以工程师为主、流程复杂的项目最大优势是可以一行行控制每一层逻辑出问题容易定位。可视化工流型则更接近传统业务系统的流程设计器你拖拽节点就能搭一个 Agent适合运营配置和快速验证。自主探索型让模型自己拆任务、自己决定调用顺序Demo 看起来很智能但一旦遇到线上真实输入很容易陷入死循环或偏离目标。多智能体协作型则把任务拆给多个角色 Agent比如一个负责规划、一个负责执行、一个负责质检适合流程边界清晰的复杂任务。4.3 选型三问我判断该用哪种风格通常会问三个问题。第一流程是确定的还是开放的。如果业务规则明确比如“先查订单状态再判断退款资格”优先选工作流如果任务本身没有固定路径比如一个研究型 Agent 要自己决定查哪些资料才需要考虑自主探索或多智能体。第二团队是工程优先还是运营优先。工程师为主的团队可以直接用代码优先写代码本身就是表达流程最快的方式如果运营经常改流程可视化工流平台会省很多沟通成本。第三项目要长期演化还是快速验证。长期产品我更推荐代码优先因为可测试、可审查、可沉淀快速 Demo 或一次性活动用可视化平台效率高得多。4.4 我在编排层踩过的几个坑早期我做 Agent 时犯过一个错误一上来就引入重量级编排框架结果连“让模型输出 JSON”这种基础能力都要花几天调试。框架本身没有错但那是杀鸡用牛刀。另一个常见的坑是把规划逻辑完全交给模型看起来好像很聪明但模型一旦编造不存在的工具或来回折腾整个 Agent 就失控了。还有一个教训是过度嵌套多 Agent本来一个 Agent 能完成的事情非要拆成三个角色互相传递消息Token 成本和延迟都翻倍。我现在做新项目时会先用最简单的工作流跑通一条路径确认逻辑稳定后再评估是否引入更重的编排框架。5. 工具层让Agent安全地把“手”伸出去工具层是 Agent 与外部世界交互的桥梁。没有工具层的 Agent 只能聊天有了工具层的 Agent 可以查数据、发通知、操作业务系统。但也正因为能“动手”工具层成了安全隐患和高成本的重灾区。5.1 工具调用不是简单发请求而是“参数校验 执行策略”模型通过 Function Calling 生成结构化调用请求后真正执行动作的是工具层代码。这里最容易忽略的是参数校验和执行策略。模型生成参数时可能多字、漏字、格式错误或者生成了一些不在预期内的值所以在执行前必须做校验。举个例子如果你的工具是查询销售数据模型把参数填成了不存在的省份也没关系工具层可以直接拦截并返回“无效参数”让模型重新生成一次。执行策略也很重要比如数据库查询必须走只读账号外部 API 请求要加超时限制敏感操作要加二次确认。这些不是模型层能替你完成的只能在工具层硬性约束。5.2 统一工具协议一次接入多个模型复用现在不少团队会同时接多个大模型不同模型的工具调用格式不完全一样。如果每个模型都单独写一套工具适配维护成本会很高。所以工具层设计时我建议采用统一工具协议和统一工具网关的思路把工具描述、参数 Schema、执行状态、错误信息标准化模型侧只需要按标准协议输出调用意图工具网关负责翻译和执行。统一工具网关还有个额外好处可以集中做鉴权、限流、审计。比如所有工具调用都经过同一个入口日志自动记录谁在什么时候调用了哪个工具、传了什么参数、结果如何尽量全量留存。这些日志对后续排障和效果分析非常有用。5.3 工具执行的安全边界工具层安全是 Agent 能不能真正进入生产环境的重要前提。我把几条硬性边界列一下每一条都是项目里验证过很有必要的数据类工具只给只读权限严禁让模型直接执行写操作。工具返回结果要裁剪只保留模型需要的字段避免超长响应塞爆上下文。涉及删除、转账、审批这类敏感动作必须走人工确认流程。所有工具调用必须埋点日志至少记录调用时间、参数、返回状态。已下线的工具要及时从工具列表中移除避免模型调用到过期接口。5.4 工具不是越多越好我建议控制在 7 个以内刚开始搭建工具层时我总想把所有能力都暴露给模型结果效果反而更差。工具一多模型经常选错工具或者在两个相似工具之间来回纠结白白消耗 Token。后来我把相似功能合并原来三个不同粒度的查询工具合并成一个带参数区分的工具之后调用准确率立竿见影地上升了。经验是单个 Agent 暴露的工具最好控制在 7 个左右不要超过认知负荷的临界值。每个工具的描述要写清楚三件事这个工具适合什么场景、参数格式是什么、执行失败时可能返回什么错误。描述写得越准确模型选错的概率越低。6. 可观测与评测决定Agent能不能上线的两件事一个 Agent 在测试环境跑得挺好不代表能上线。真正决定它能不能扛住真实流量的是可观测能力和评测体系。这两件事在我接触的团队里经常被拖到最后一刻然后被迫补课。6.1 从 Trace 开始一次回答背后是一串不可见调用Agent 的回答很少是一步生成出来的它可能经历了“意图识别、工具调用、检索召回、结果重排、最终生成”多个环节。任何一个环节出错最终结果都会偏。所以可观测性是 Agent 技术栈里不能省的一层。我的做法是至少记录每次 LLM 调用的输入、输出、耗时、Token 数记录每条工具调用的参数、返回状态、错误信息并把完整链路串成一个 Trace。排查问题时先看 Trace 里哪一步异常如果工具返回了错误就到工具层找原因如果检索结果为空就到记忆层看分段策略如果每一步都正常但最终回答不符合要求那问题多半出在 Prompt 或模型选择上。6.2 评测集是 Agent 的“验收单”没有评测集Agent 项目的改进就是打地鼠修好一个 Bug又冒出新 Bug。我通常会准备 20 到 30 个固定用例覆盖正常问题、边界问题、缺参数问题、恶意输入和空结果场景同时写下每个用例的期望行为。每次修改 Prompt、切换模型、调整工具之后这批用例都会完整重跑一遍。评测维度我会拆成几个方面回答是否达到预期、格式是否符合要求、工具调用是否必要和正确、是否在不确定时主动说明而不是瞎编。第一次可以人工打分跑熟之后可以脚本自动比对关键字段只有自动分和人工抽查都过了才允许上线。这个环节的意义不是追求分数好看而是防止“修好的问题在下一次改动里复发”。6.3 一套最小可行的评测流程我的最小评测流程大概是这样先定义评测集把每个用例的期望行为写清楚然后用批量脚本跑一遍自动记录结果接着人工抽检一部分典型 case重点看模型判断和工具调用质量最后把 Bad Case 整理出来分析问题是模型层、记忆层还是工具层修复后全量回归一遍。这套流程不需要一开始就用复杂平台一个脚本加一张表就能跑起来。但一旦项目进入持续迭代阶段评测集就是唯一能让你放心改动的基础设施。7. 落地避坑与我的最小起步路径前面讲完五层的拆解最后说说整体落地时最容易踩的坑以及我自己的最小起步路径。7.1 五个最容易让 Agent 项目胎死腹中的问题常见症状背后原因建议方向Prompt 写了一长串模型仍不按预期执行指令遵循能力不足或结构混乱拆解指令加入示例分步验证回答引用了不存在的资料检索片段没有来源标注给片段编号要求模型引用编号工具调用经常失败或选错工具工具描述不清或工具数量过多合并相似工具优化描述Token 成本快速失控上下文无限堆叠工具调用反复失败摘要压缩限制上下文长度改了 Prompt 后旧问题复发缺少评测集和回归流程建立最小评测集每次改动全量回归7.2 从 0 到 1 的最小技术栈很多团队想把 Agent 一步到位结果把技术栈搭得很重项目却迟迟跑不起来。我的建议是反过来先做一个最小的闭环能够处理一条最简单的业务线就够了。Model 用成熟 API 接入记忆层先用会话摘要加简单检索工具层只接一个核心工具编排层先用工作流把固定步骤写死再加一份基础日志。先把这条链路跑通验证业务价值和用户反馈然后再逐步扩展加第二个工具、引入向量检索、尝试更复杂的编排策略。这样做的最大好处是你每一步的改动都有基准出了问题知道影响面在哪里。7.3 我对技术栈迭代的态度遇到新框架我现在的习惯是先冷静看几件事它替代的是哪一层它跟当前实现的差异是什么它能不能解决我此刻真正在痛的痛点如果答案不够明确就在隔离环境里把旧实现重写一遍做对比而不是直接割接。技术栈本身是工具不是信仰适合当前阶段的就是最好的。如果只让我留一条建议给刚接触 Agent 技术栈的人先找一个足够小的场景把一个最小的 Agent 完整跑通再回来看这张全景图。全景图能帮你理解全貌但真正让你把每一层记住的永远是那些线上出了 Bug 之后顺着 Trace 一层层往回定位的夜晚。