但凡最近半年在做 AI 应用开发的人应该都躲不开一个词Agent。朋友圈里教程转疯了GitHub 上 agent 项目一个比一个火连专利辅助工具都开始往 Agent 方向靠。但真正在落地做项目的团队会很快发现问题从来不出在“能不能调通大模型”而是出在数据和基础设施上。今天这篇我想沿着“数据·智能·进化”这条主线把 Agent 时代的数据体系和 AI 基础设施这个话题完整理一遍。文章适合正在做 Agent 应用、或者准备从 RAG 转向 Agent 架构的开发者、数据工程师和技术负责人里面没有纯理论的空谈基本都是我在生产环境里踩过的坑和验证过的方案。1. Agent 时代数据与 AI 基础设施到底哪里变了1.1 从“能读”到“能干”Agent 给数据提出了新要求传统的 LLM 应用本质上是“读书型”产品。用户问一个问题系统去检索知识库、拼上下文再让模型回答。说白了是把模型当成一个读过很多书的回答者它的能力上限取决于“读到了什么”。Agent 应用则是“干活型”产品。用户丢过来一个目标比如“分析这个月的销售数据并生成一份可执行的增长策略”Agent 要自己拆解任务先找数据再清洗再分析再写报告。每一步都需要调用真实的数据接口和工具。模型确实还是那个模型但对数据和基础设施的要求完全变了。我在实际项目里最直观的感受是以前做 RAG把文档切好、索引建好检索准确率做到八成以上体验就还能接受。但到了 Agent 场景同样一个检索模块失败率哪怕只有 5%整个任务链都可能崩掉——因为 Agent 会基于错误信息继续往下走而它自己并不知道错。这个差异不是量变是质变。1.2 旧基建的三个“不”时效不跟、上下文不够、转换不灵我帮不少团队做过技术方案评审发现大家用传统数据基建去跑 Agent普遍会撞上三堵墙。第一堵墙叫“时效跟不上”。传统数仓、BI 的数据链路是 T1 甚至 T2 设计昨天跑批、今早出报表这在看板场景没问题。但 Agent 要处理的往往是“现在此刻”的数据实时库存、当前订单、线上日志。Agent 拿着昨天的数据去回答“现在怎么样”结果就是一本正经地胡说八道。第二堵墙叫“上下文装不下”。Agent 的任务链路很长中间会经历多轮工具调用每轮都会带回新的数据。模型上下文窗口是有限的而业务数据可能是无限的。很多团队做到后面会发现真正卡住 Agent 的不是模型能力而是怎么在有限的上下文里塞进“当前最重要”的数据同时又不挤掉用户目标和中间结果。第三堵墙叫“结构化转换不灵活”。模型输出的是自然语言工具和数据库要的是结构化参数。比如 Agent 说“查一下张三上个月的订单”底层 API 需要的是 user_id 和 date_range。这个转换如果靠硬编码规则稍微复杂一点就崩。数据基础设施必须把这层“自然语言到结构化调用”的桥搭稳但很多传统数据平台根本没有这一层。1.3 数据从“训练原料”变成“运行时燃料”这个比喻可能有点抽象我换个说法以前数据是“一次性食材”买回来腌好炒熟从此定型。模型训练或微调完了数据就封存在那里。Agent 时代数据是“活水”——每次任务执行模型都要动态地取一段数据、做一次推理、反馈一个结果而这个结果又成为下一次决策的新输入。这意味着数据管道的设计逻辑要转变不光是批处理和 ETL还要有流式接入、实时检索、动态注入、反馈回流。做数据架构的同事要开始把自己当成“给 Agent 供血的人”而不是“给报表供数的人”。数据、智能、进化这三个词放到一起看其实就是一条线数据喂给智能智能执行任务执行结果再沉淀成新数据形成进化的闭环。2. 面向 Agent 的数据体系怎么搭2.1 数据分级把数据当 CPU 缓存来设计Agent 的数据需求我建议按照“使用频率”和“时效要求”分级来规划。这个思路跟我给团队画的架构图已经绑定在一起了分级表如下层级典型数据存储方式时效要求主要消费方L1 当前上下文对话记录、本轮工具结果内存/会话缓存毫秒级模型推理L2 工作记忆子任务状态、执行计划会话存储/Redis任务结束前Agent 编排器L3 情景记忆历史任务摘要、偏好向量库分钟级记忆检索模块L4 知识库产品文档、FAQ、规范向量库关系库小时/天级RAG 检索L5 归档数据日志、审计、训练集对象存储/数仓长期保存离线分析、微调这个分级的核心价值是让“什么数据该在什么位置”这件事变得可管理。数据没有分层Agent 的输入就会变成一个大杂烩。分完层之后每一个数据源由谁维护、多久更新一次、故障时对 Agent 的影响是什么都能说得清楚。2.2 记忆不能只靠向量库得分成三套来管很多人一提 Agent 记忆就说“上向量数据库”这其实是个误区。向量库擅长的是“语义相似检索”但它不擅长记录任务状态、维护执行栈、管理临时变量。就好比你不能用搜索引擎来记账也不能用账本做相似度查找——工具本身没问题问题是拿错了锤子。我在生产项目里会给 Agent 配三套记忆。工作记忆放在 Redis 或本地状态容器里保存“当前任务做到哪一步了”“调了哪些工具”“哪些依赖还没满足”。这是 Agent 不迷路的根本。情景记忆在每个任务结束后写入把关键信息清洗、压缩、总结成结构化摘要存进向量库下次接到类似任务时先检索“以前怎么做的”再制定计划。语义记忆则是沉淀下来的业务知识包括文档、FAQ、最佳实践面向具体场景做索引。这里有个关键情景记忆的摘要质量直接决定 Agent 的长期能力。摘要不是简单截断而是有选择地保留四类信息——任务目标、关键决策、工具调用序列、最终结果。我见过不少团队随便把完整对话丢进向量库结果检索出来一大堆噪音模型还被误导。2.3 知识库与工具数据的接入方式知识库这块做 RAG 的团队已经很熟了但 Agent 场景有三个额外要求必须强调权限、版本、引用。权限问题是老大难。Agent 如果访问了不该访问的数据不是“泄露给用户”而是“泄露给模型再泄露给用户”危害翻倍。我常用的做法是在检索层之前加一道数据访问过滤器用元数据部门、密级过滤候选文档而不是在展示层才处理。版本问题容易被忽略。产品文档改了向量库里还是旧版Agent 就会拿着旧规范干活。我的做法是给文档加版本号检索结果带上 version 字段必要时让模型判断版本一致性。工具数据的接入方式则完全不一样。工具 API 暴露给 Agent 的除了数据本身更重要的是清晰的 Schema——字段名、类型、枚举值、示例。大模型不像传统程序那样去读接口文档它靠你给的函数描述来理解怎么调用。描述写得好不好直接决定调用成功率。2.4 数据质量与时效性控制Agent 比人更依赖数据质量因为人要为自己的判断负责但 Agent“自信地胡说”的能力特别强。我给团队定了几条硬规矩新鲜度校验每次给 Agent 注入数据前必须带时间戳超过有效期的数据不注入。冲突检测同一指标不同来源数值不一致时必须有优先级规则否则交给 Agent 自作主张等于埋雷。反馈回流Agent 执行每个工具后成功还是失败、用时多少、是否需要重试都要记下来。这些反馈数据就是下一轮优化的原料。敏感信息脱敏日志和上下文里不允许出现明文密钥、身份证号、银行卡号。这要在管道层强制而不是靠模型自觉。这么做的原因很简单数据不可信Agent 的每一步推理都建立在流沙上。宁可让 Agent 说“我不知道”也不能让它拿着脏数据自信地给出错误结论。3. AI 基础设施的选型逻辑与落地架构3.1 五层拆解先有框架再选组件AI 基础设施我建议按五层拆解每一层职责清晰避免什么都往“向量数据库”里塞模型服务层大模型推理、微调、缓存负责“智能”。数据接入层实时流、批处理、API 网关负责“喂数据”。检索与记忆层向量检索、记忆管理、短文本缓存负责“取数据”。执行编排层Agent 框架、任务调度、工具注册负责“干活”。可观测与治理层日志、链路追踪、评估、成本控制负责“不翻车”。这个分层不是学术空想是我踩坑踩出来的。早期我倾向于“用一套开源框架解决所有问题”结果编排、存储、检索耦合在一起升级任何一个组件都牵一发动全身。拆层之后每一层可以独立演进、独立扩容排障的时候也容易定位——是模型的问题、检索的问题还是编排挂掉了。3.2 向量数据库选型对照选型对比我直接放表都是实际用过的组合方案部署形态数据规模适合场景我的评价pgvectorPostgres 插件千万级以下中小项目、已有 PG最省事能和业务数据放一起Qdrant独立服务亿级生产级、中文场景好资源占用适中API 友好Milvus独立集群十亿级大规模、高并发功能强但运维成本高Weaviate独立服务亿级多模态检索模块化设计漂亮Elasticsearch已有集群亿级混合检索团队会 ES 就优先用它给一个很实在的建议数据量没到千万级别为了“前沿”去上重型分布式向量库。pgvector 配上好的切分策略和重排逻辑在大多数 Agent 业务场景下完全够用。组件越少出问题的环节越少这一点在线上故障时体会特别深。3.3 编排框架与 Agent 运行时怎么选Agent 框架卷得很厉害LangChain、LlamaIndex、AutoGen、自研编排……选择成本比组件本身高得多。我的判断标准很简单看你的 Agent 是“先规划后执行”还是“边执行边规划”。如果是“先规划后执行”的确定性流程比如客服工单自动化图编排框架很合适节点明确、流程可控。如果是“边执行边规划”的开放式探索比如研究型 Agent那就需要更灵活的循环式框架或者直接自研轻量编排器。我的偏好是核心编排逻辑尽量薄、尽量透明不把业务写死在框架里。框架解决的是工具调用循环、上下文维护、状态传递这三件事其他的一切用什么模型、存什么记忆都应由业务层控制。永远不要让框架成为你项目能力的上限。建议从零起步的团队先别迷信“自动规划”。手动写死前几个步骤把数据管道跑通再逐步放开让 Agent 自主决策。循序渐进能帮你省掉大量调试的烦恼。3.4 可观测性链路追踪与成本治理Agent 应用排查问题比传统微服务难得多。一次任务可能调用 5 个工具、4 次模型、读了 20 段文档任何一个环节出错表象都是“回答不对”。没有全链路追踪你根本不知道是卡在检索、卡在模型、还是卡在工具。我在项目里会用两类日志。一类是结构化操作日志记录每一步的关键参数和耗时比如检索了什么、调用了什么、返回了什么。另一类是“决策日志”记录模型当时的决策理由和备选方案。后者对排查“为什么 Agent 走了错误分支”特别有帮助。成本治理这块我见过不止一个团队被账单吓到。Agent 任务比普通问答贵一个数量级——多轮模型调用、频繁检索、长上下文都是钱。我的做法是三级控制单任务 token 预算上限模型分级调用简单操作用便宜的小模型复杂推理才用旗舰模型结果缓存相同或相似请求直接命中缓存不重复推理。实测下来缓存能省掉三到四成的成本。4. 实操记录一个最小可用 Agent 数据链路4.1 记忆模块上下文压缩与写入策略直接给一段项目里用的伪代码说明情景记忆怎么写def write_memory(task_id, conversation, memory_store): # 1. 抽取关键信息目标、决策、工具调用链、结果 summary llm.summarize( conversation, fields[task_goal, key_decisions, tool_sequence, final_result] ) # 2. 带上元数据任务ID、时间、业务域 memory_item { embedding: embed(summary), metadata: { task_id: task_id, created_at: now(), domain: detect_domain(conversation), }, content: summary, } # 3. 写入向量库触发索引更新 memory_store.upsert(memory_item)几个容易踩的坑我直接说出来一是别全量存对话对话太长且噪音多检索性价比极差二是 metadata 必须带全否则后面想按业务线过滤记忆时只能重新打标三是摘要生成本身要耗一次模型调用别在循环里反复触发批量任务结束后统一处理。工作记忆的实现要快用 Redis 这类带过期时间的内存存储key 按任务 ID 组织value 存当前计划、已完成步骤、待办列表。任务结束或超时自动清理避免内存堆积。4.2 从“搜到”到“够用”知识库检索的工程修正RAG 检索最怕的是“分数很高但内容不对”。我在生产里做了三道修正。第一道相似度阈值。低于阈值的片段宁可不给也不要硬塞给模型。我在项目里设过 0.75 的阈值低于这条线的检索结果直接丢弃。宁缺毋滥比硬凑好。第二道重排。向量初筛召回 top100再用重排模型精排取 top5。初筛靠语义向量快筛精排靠交叉编码器做细粒度判断两层配合效果远好于单层。第三道引用验证。给模型的提示词里强制要求回答中引用的每一条信息必须附上来源文档 ID 和片段位置。如果模型答了几条“查无此据”的内容说明检索注入出了问题立刻报警。三道修正做完检索准确率从初期的七成左右提到了九成以上。别嫌麻烦这一步省不下来。4.3 反馈闭环执行结果回流成“经验数据”Agent 最有价值的地方在于每一次执行都是数据生成的时刻。工具调用成功、失败、超时、重试这些结果如果不回流那 Agent 就永远是“每次从零开始”。项目里的反馈记录模块长这样def record_feedback(task_id, tool_name, ok, latency, error_msg): fp ffeedback/{tool_name} # 统计指标 incr(f{fp}:total) incr(f{fp}:ok if ok else f{fp}:fail) observe(f{fp}:latency, latency) # 记录典型失败信息供人分析 if not ok: log_error(task_id, tool_name, error_msg)这些数据积累起来有三个用途一是统计哪个工具最容易失败优先优化二是做 Agent 评估时用真实执行数据而不是拍脑袋用例三是未来做工具推荐或自动重试策略时这些是训练素材。数据飞轮就是这么转起来的——每一次线上执行都在为体系的进化贡献数据。4.4 Token 预算与缓存设计给一个可以抄作业的计算方式。假设上下文窗口是 8k token任务目标大概占 1k系统提示词占 1k那实际能分给外部数据的预算大约是 6k。检索 3 段文档每段精排后控制在 1.5k 左右就占 4.5k还剩 1.5k 留给工具结果和中间推理。这看起来紧张所以必须控制检索片段长度和工具返回字段。我的做法有两个。一是检索前先做意图识别只带和当前子任务相关的片段而不是把所有检索结果一股脑塞进上下文。二是工具返回字段裁剪——API 把用户 full record 全量返回Agent 只需要用户 ID 和名称那就用中间层把字段裁掉。上下文里堆一堆无用字段模型推理质量会肉眼可见地下降。缓存设计同样重要。知识库片段按文档 hash 做永久缓存工具返回按参数 hash 做短期缓存模型推理结果做语义缓存命中条件比较严格。实测下来缓存能省掉三到四成的成本也降低了接口压力的风险。5. 常见问题与排查技巧实录5.1 高频问题速查表把线上遇到的高频问题整理成速查表按“症状→原因→解法”排列症状可能原因排查方向与解法Agent 反复调用同一个工具停不下来循环缺少终止条件或上一次结果未正确记录检查编排器的状态判断增加最大调用次数限制回答很自信但内容完全错误检索数据有噪音或上下文冲突检查知识库引用开启引用验证降低相似度阈值任务中途失败报 agent execution terminated子任务抛异常编排层未捕获给每个子任务加独立异常捕获和降级策略上下文被塞爆模型开始“忘记”目标检索和工具返回未做裁剪做字段裁剪、片段长度限制、数据分级注入数据接口返回 502 或超时上游接口不稳定或并发过高加重试、熔断、缓存把接口状态纳入监控每次答案都不一样检索排序不稳定或模型温度设置过高固定重排逻辑降低 temperature加缓存成本翻倍无效重试、重复注入、未分级调用模型加 token 预算、结果缓存、模型分级路由5.2 两个典型问题的排查过程先说循环调用。有一次线上 Agent 在“查询用户订单”这个工具上反复调用日志显示它每次返回都跟期望不一致。我沿着决策日志往下看发现模型在工具返回中读到一条字段 updated_at但当前时间和它预期对不上就认为是“数据没更新”于是重试。根因不是模型问题而是 API 返回的时间字段时区没处理。修好时区统一后循环立刻消失。再说“自信胡说”。有一次做产品推荐Agent 言之凿凿说某商品打折实际促销已结束。排查发现知识库里有旧版促销文档向量检索按语义召回了这段历史内容模型没有能力判断时效就当成事实输出了。后来我们强制每个知识片段带生效时间和过期时间并把这俩字段注入提示词让模型明确“过期内容不得作为事实引用”问题才被压下去。这两个案例的共同教训是Agent 的错误几乎总是数据问题而不是模型问题。数据不干净模型再聪明也白搭。5.3 写在最后的小经验按惯例分享几条非官方文档里不会写的经验。第一上线前必须有一组“最低可用的评估用例”。我见过太多团队上线全靠人肉点测出问题才后悔。最少要有十条覆盖主要路径的用例每次改数据管道先跑一遍回归成本不高收益巨大。第二工具 Schema 要像写接口文档一样认真。字段、类型、枚举值、示例一个都不能少还要写清楚“什么时候不要调用这个工具”。很多 Agent 乱调工具根源就是 Schema 没写边界。第三别急着上分布式和 K8s。单机、Postgres、一个编排器先把业务跑通把数据流看清再谈规模。Agent 基础设施的复杂度应该是被业务逼出来的而不是被技术焦虑逼出来的。我在实际操作中最深的一个体会是Agent 的真正瓶颈从来不是模型本身而是数据的质量和基础设施的韧性。一个数据管道混乱的团队换再强的模型也救不回来而把数据分级、记忆分层、反馈闭环这三件事做好哪怕模型不是最强的Agent 的整体表现也不会差。大家如果正在做或准备做 Agent 相关的项目不妨先停下来把数据这条线理清楚再往前跑——这个投入一定值得。
Agent时代的数据体系与AI基础设施：从RAG到智能体落地
但凡最近半年在做 AI 应用开发的人应该都躲不开一个词Agent。朋友圈里教程转疯了GitHub 上 agent 项目一个比一个火连专利辅助工具都开始往 Agent 方向靠。但真正在落地做项目的团队会很快发现问题从来不出在“能不能调通大模型”而是出在数据和基础设施上。今天这篇我想沿着“数据·智能·进化”这条主线把 Agent 时代的数据体系和 AI 基础设施这个话题完整理一遍。文章适合正在做 Agent 应用、或者准备从 RAG 转向 Agent 架构的开发者、数据工程师和技术负责人里面没有纯理论的空谈基本都是我在生产环境里踩过的坑和验证过的方案。1. Agent 时代数据与 AI 基础设施到底哪里变了1.1 从“能读”到“能干”Agent 给数据提出了新要求传统的 LLM 应用本质上是“读书型”产品。用户问一个问题系统去检索知识库、拼上下文再让模型回答。说白了是把模型当成一个读过很多书的回答者它的能力上限取决于“读到了什么”。Agent 应用则是“干活型”产品。用户丢过来一个目标比如“分析这个月的销售数据并生成一份可执行的增长策略”Agent 要自己拆解任务先找数据再清洗再分析再写报告。每一步都需要调用真实的数据接口和工具。模型确实还是那个模型但对数据和基础设施的要求完全变了。我在实际项目里最直观的感受是以前做 RAG把文档切好、索引建好检索准确率做到八成以上体验就还能接受。但到了 Agent 场景同样一个检索模块失败率哪怕只有 5%整个任务链都可能崩掉——因为 Agent 会基于错误信息继续往下走而它自己并不知道错。这个差异不是量变是质变。1.2 旧基建的三个“不”时效不跟、上下文不够、转换不灵我帮不少团队做过技术方案评审发现大家用传统数据基建去跑 Agent普遍会撞上三堵墙。第一堵墙叫“时效跟不上”。传统数仓、BI 的数据链路是 T1 甚至 T2 设计昨天跑批、今早出报表这在看板场景没问题。但 Agent 要处理的往往是“现在此刻”的数据实时库存、当前订单、线上日志。Agent 拿着昨天的数据去回答“现在怎么样”结果就是一本正经地胡说八道。第二堵墙叫“上下文装不下”。Agent 的任务链路很长中间会经历多轮工具调用每轮都会带回新的数据。模型上下文窗口是有限的而业务数据可能是无限的。很多团队做到后面会发现真正卡住 Agent 的不是模型能力而是怎么在有限的上下文里塞进“当前最重要”的数据同时又不挤掉用户目标和中间结果。第三堵墙叫“结构化转换不灵活”。模型输出的是自然语言工具和数据库要的是结构化参数。比如 Agent 说“查一下张三上个月的订单”底层 API 需要的是 user_id 和 date_range。这个转换如果靠硬编码规则稍微复杂一点就崩。数据基础设施必须把这层“自然语言到结构化调用”的桥搭稳但很多传统数据平台根本没有这一层。1.3 数据从“训练原料”变成“运行时燃料”这个比喻可能有点抽象我换个说法以前数据是“一次性食材”买回来腌好炒熟从此定型。模型训练或微调完了数据就封存在那里。Agent 时代数据是“活水”——每次任务执行模型都要动态地取一段数据、做一次推理、反馈一个结果而这个结果又成为下一次决策的新输入。这意味着数据管道的设计逻辑要转变不光是批处理和 ETL还要有流式接入、实时检索、动态注入、反馈回流。做数据架构的同事要开始把自己当成“给 Agent 供血的人”而不是“给报表供数的人”。数据、智能、进化这三个词放到一起看其实就是一条线数据喂给智能智能执行任务执行结果再沉淀成新数据形成进化的闭环。2. 面向 Agent 的数据体系怎么搭2.1 数据分级把数据当 CPU 缓存来设计Agent 的数据需求我建议按照“使用频率”和“时效要求”分级来规划。这个思路跟我给团队画的架构图已经绑定在一起了分级表如下层级典型数据存储方式时效要求主要消费方L1 当前上下文对话记录、本轮工具结果内存/会话缓存毫秒级模型推理L2 工作记忆子任务状态、执行计划会话存储/Redis任务结束前Agent 编排器L3 情景记忆历史任务摘要、偏好向量库分钟级记忆检索模块L4 知识库产品文档、FAQ、规范向量库关系库小时/天级RAG 检索L5 归档数据日志、审计、训练集对象存储/数仓长期保存离线分析、微调这个分级的核心价值是让“什么数据该在什么位置”这件事变得可管理。数据没有分层Agent 的输入就会变成一个大杂烩。分完层之后每一个数据源由谁维护、多久更新一次、故障时对 Agent 的影响是什么都能说得清楚。2.2 记忆不能只靠向量库得分成三套来管很多人一提 Agent 记忆就说“上向量数据库”这其实是个误区。向量库擅长的是“语义相似检索”但它不擅长记录任务状态、维护执行栈、管理临时变量。就好比你不能用搜索引擎来记账也不能用账本做相似度查找——工具本身没问题问题是拿错了锤子。我在生产项目里会给 Agent 配三套记忆。工作记忆放在 Redis 或本地状态容器里保存“当前任务做到哪一步了”“调了哪些工具”“哪些依赖还没满足”。这是 Agent 不迷路的根本。情景记忆在每个任务结束后写入把关键信息清洗、压缩、总结成结构化摘要存进向量库下次接到类似任务时先检索“以前怎么做的”再制定计划。语义记忆则是沉淀下来的业务知识包括文档、FAQ、最佳实践面向具体场景做索引。这里有个关键情景记忆的摘要质量直接决定 Agent 的长期能力。摘要不是简单截断而是有选择地保留四类信息——任务目标、关键决策、工具调用序列、最终结果。我见过不少团队随便把完整对话丢进向量库结果检索出来一大堆噪音模型还被误导。2.3 知识库与工具数据的接入方式知识库这块做 RAG 的团队已经很熟了但 Agent 场景有三个额外要求必须强调权限、版本、引用。权限问题是老大难。Agent 如果访问了不该访问的数据不是“泄露给用户”而是“泄露给模型再泄露给用户”危害翻倍。我常用的做法是在检索层之前加一道数据访问过滤器用元数据部门、密级过滤候选文档而不是在展示层才处理。版本问题容易被忽略。产品文档改了向量库里还是旧版Agent 就会拿着旧规范干活。我的做法是给文档加版本号检索结果带上 version 字段必要时让模型判断版本一致性。工具数据的接入方式则完全不一样。工具 API 暴露给 Agent 的除了数据本身更重要的是清晰的 Schema——字段名、类型、枚举值、示例。大模型不像传统程序那样去读接口文档它靠你给的函数描述来理解怎么调用。描述写得好不好直接决定调用成功率。2.4 数据质量与时效性控制Agent 比人更依赖数据质量因为人要为自己的判断负责但 Agent“自信地胡说”的能力特别强。我给团队定了几条硬规矩新鲜度校验每次给 Agent 注入数据前必须带时间戳超过有效期的数据不注入。冲突检测同一指标不同来源数值不一致时必须有优先级规则否则交给 Agent 自作主张等于埋雷。反馈回流Agent 执行每个工具后成功还是失败、用时多少、是否需要重试都要记下来。这些反馈数据就是下一轮优化的原料。敏感信息脱敏日志和上下文里不允许出现明文密钥、身份证号、银行卡号。这要在管道层强制而不是靠模型自觉。这么做的原因很简单数据不可信Agent 的每一步推理都建立在流沙上。宁可让 Agent 说“我不知道”也不能让它拿着脏数据自信地给出错误结论。3. AI 基础设施的选型逻辑与落地架构3.1 五层拆解先有框架再选组件AI 基础设施我建议按五层拆解每一层职责清晰避免什么都往“向量数据库”里塞模型服务层大模型推理、微调、缓存负责“智能”。数据接入层实时流、批处理、API 网关负责“喂数据”。检索与记忆层向量检索、记忆管理、短文本缓存负责“取数据”。执行编排层Agent 框架、任务调度、工具注册负责“干活”。可观测与治理层日志、链路追踪、评估、成本控制负责“不翻车”。这个分层不是学术空想是我踩坑踩出来的。早期我倾向于“用一套开源框架解决所有问题”结果编排、存储、检索耦合在一起升级任何一个组件都牵一发动全身。拆层之后每一层可以独立演进、独立扩容排障的时候也容易定位——是模型的问题、检索的问题还是编排挂掉了。3.2 向量数据库选型对照选型对比我直接放表都是实际用过的组合方案部署形态数据规模适合场景我的评价pgvectorPostgres 插件千万级以下中小项目、已有 PG最省事能和业务数据放一起Qdrant独立服务亿级生产级、中文场景好资源占用适中API 友好Milvus独立集群十亿级大规模、高并发功能强但运维成本高Weaviate独立服务亿级多模态检索模块化设计漂亮Elasticsearch已有集群亿级混合检索团队会 ES 就优先用它给一个很实在的建议数据量没到千万级别为了“前沿”去上重型分布式向量库。pgvector 配上好的切分策略和重排逻辑在大多数 Agent 业务场景下完全够用。组件越少出问题的环节越少这一点在线上故障时体会特别深。3.3 编排框架与 Agent 运行时怎么选Agent 框架卷得很厉害LangChain、LlamaIndex、AutoGen、自研编排……选择成本比组件本身高得多。我的判断标准很简单看你的 Agent 是“先规划后执行”还是“边执行边规划”。如果是“先规划后执行”的确定性流程比如客服工单自动化图编排框架很合适节点明确、流程可控。如果是“边执行边规划”的开放式探索比如研究型 Agent那就需要更灵活的循环式框架或者直接自研轻量编排器。我的偏好是核心编排逻辑尽量薄、尽量透明不把业务写死在框架里。框架解决的是工具调用循环、上下文维护、状态传递这三件事其他的一切用什么模型、存什么记忆都应由业务层控制。永远不要让框架成为你项目能力的上限。建议从零起步的团队先别迷信“自动规划”。手动写死前几个步骤把数据管道跑通再逐步放开让 Agent 自主决策。循序渐进能帮你省掉大量调试的烦恼。3.4 可观测性链路追踪与成本治理Agent 应用排查问题比传统微服务难得多。一次任务可能调用 5 个工具、4 次模型、读了 20 段文档任何一个环节出错表象都是“回答不对”。没有全链路追踪你根本不知道是卡在检索、卡在模型、还是卡在工具。我在项目里会用两类日志。一类是结构化操作日志记录每一步的关键参数和耗时比如检索了什么、调用了什么、返回了什么。另一类是“决策日志”记录模型当时的决策理由和备选方案。后者对排查“为什么 Agent 走了错误分支”特别有帮助。成本治理这块我见过不止一个团队被账单吓到。Agent 任务比普通问答贵一个数量级——多轮模型调用、频繁检索、长上下文都是钱。我的做法是三级控制单任务 token 预算上限模型分级调用简单操作用便宜的小模型复杂推理才用旗舰模型结果缓存相同或相似请求直接命中缓存不重复推理。实测下来缓存能省掉三到四成的成本。4. 实操记录一个最小可用 Agent 数据链路4.1 记忆模块上下文压缩与写入策略直接给一段项目里用的伪代码说明情景记忆怎么写def write_memory(task_id, conversation, memory_store): # 1. 抽取关键信息目标、决策、工具调用链、结果 summary llm.summarize( conversation, fields[task_goal, key_decisions, tool_sequence, final_result] ) # 2. 带上元数据任务ID、时间、业务域 memory_item { embedding: embed(summary), metadata: { task_id: task_id, created_at: now(), domain: detect_domain(conversation), }, content: summary, } # 3. 写入向量库触发索引更新 memory_store.upsert(memory_item)几个容易踩的坑我直接说出来一是别全量存对话对话太长且噪音多检索性价比极差二是 metadata 必须带全否则后面想按业务线过滤记忆时只能重新打标三是摘要生成本身要耗一次模型调用别在循环里反复触发批量任务结束后统一处理。工作记忆的实现要快用 Redis 这类带过期时间的内存存储key 按任务 ID 组织value 存当前计划、已完成步骤、待办列表。任务结束或超时自动清理避免内存堆积。4.2 从“搜到”到“够用”知识库检索的工程修正RAG 检索最怕的是“分数很高但内容不对”。我在生产里做了三道修正。第一道相似度阈值。低于阈值的片段宁可不给也不要硬塞给模型。我在项目里设过 0.75 的阈值低于这条线的检索结果直接丢弃。宁缺毋滥比硬凑好。第二道重排。向量初筛召回 top100再用重排模型精排取 top5。初筛靠语义向量快筛精排靠交叉编码器做细粒度判断两层配合效果远好于单层。第三道引用验证。给模型的提示词里强制要求回答中引用的每一条信息必须附上来源文档 ID 和片段位置。如果模型答了几条“查无此据”的内容说明检索注入出了问题立刻报警。三道修正做完检索准确率从初期的七成左右提到了九成以上。别嫌麻烦这一步省不下来。4.3 反馈闭环执行结果回流成“经验数据”Agent 最有价值的地方在于每一次执行都是数据生成的时刻。工具调用成功、失败、超时、重试这些结果如果不回流那 Agent 就永远是“每次从零开始”。项目里的反馈记录模块长这样def record_feedback(task_id, tool_name, ok, latency, error_msg): fp ffeedback/{tool_name} # 统计指标 incr(f{fp}:total) incr(f{fp}:ok if ok else f{fp}:fail) observe(f{fp}:latency, latency) # 记录典型失败信息供人分析 if not ok: log_error(task_id, tool_name, error_msg)这些数据积累起来有三个用途一是统计哪个工具最容易失败优先优化二是做 Agent 评估时用真实执行数据而不是拍脑袋用例三是未来做工具推荐或自动重试策略时这些是训练素材。数据飞轮就是这么转起来的——每一次线上执行都在为体系的进化贡献数据。4.4 Token 预算与缓存设计给一个可以抄作业的计算方式。假设上下文窗口是 8k token任务目标大概占 1k系统提示词占 1k那实际能分给外部数据的预算大约是 6k。检索 3 段文档每段精排后控制在 1.5k 左右就占 4.5k还剩 1.5k 留给工具结果和中间推理。这看起来紧张所以必须控制检索片段长度和工具返回字段。我的做法有两个。一是检索前先做意图识别只带和当前子任务相关的片段而不是把所有检索结果一股脑塞进上下文。二是工具返回字段裁剪——API 把用户 full record 全量返回Agent 只需要用户 ID 和名称那就用中间层把字段裁掉。上下文里堆一堆无用字段模型推理质量会肉眼可见地下降。缓存设计同样重要。知识库片段按文档 hash 做永久缓存工具返回按参数 hash 做短期缓存模型推理结果做语义缓存命中条件比较严格。实测下来缓存能省掉三到四成的成本也降低了接口压力的风险。5. 常见问题与排查技巧实录5.1 高频问题速查表把线上遇到的高频问题整理成速查表按“症状→原因→解法”排列症状可能原因排查方向与解法Agent 反复调用同一个工具停不下来循环缺少终止条件或上一次结果未正确记录检查编排器的状态判断增加最大调用次数限制回答很自信但内容完全错误检索数据有噪音或上下文冲突检查知识库引用开启引用验证降低相似度阈值任务中途失败报 agent execution terminated子任务抛异常编排层未捕获给每个子任务加独立异常捕获和降级策略上下文被塞爆模型开始“忘记”目标检索和工具返回未做裁剪做字段裁剪、片段长度限制、数据分级注入数据接口返回 502 或超时上游接口不稳定或并发过高加重试、熔断、缓存把接口状态纳入监控每次答案都不一样检索排序不稳定或模型温度设置过高固定重排逻辑降低 temperature加缓存成本翻倍无效重试、重复注入、未分级调用模型加 token 预算、结果缓存、模型分级路由5.2 两个典型问题的排查过程先说循环调用。有一次线上 Agent 在“查询用户订单”这个工具上反复调用日志显示它每次返回都跟期望不一致。我沿着决策日志往下看发现模型在工具返回中读到一条字段 updated_at但当前时间和它预期对不上就认为是“数据没更新”于是重试。根因不是模型问题而是 API 返回的时间字段时区没处理。修好时区统一后循环立刻消失。再说“自信胡说”。有一次做产品推荐Agent 言之凿凿说某商品打折实际促销已结束。排查发现知识库里有旧版促销文档向量检索按语义召回了这段历史内容模型没有能力判断时效就当成事实输出了。后来我们强制每个知识片段带生效时间和过期时间并把这俩字段注入提示词让模型明确“过期内容不得作为事实引用”问题才被压下去。这两个案例的共同教训是Agent 的错误几乎总是数据问题而不是模型问题。数据不干净模型再聪明也白搭。5.3 写在最后的小经验按惯例分享几条非官方文档里不会写的经验。第一上线前必须有一组“最低可用的评估用例”。我见过太多团队上线全靠人肉点测出问题才后悔。最少要有十条覆盖主要路径的用例每次改数据管道先跑一遍回归成本不高收益巨大。第二工具 Schema 要像写接口文档一样认真。字段、类型、枚举值、示例一个都不能少还要写清楚“什么时候不要调用这个工具”。很多 Agent 乱调工具根源就是 Schema 没写边界。第三别急着上分布式和 K8s。单机、Postgres、一个编排器先把业务跑通把数据流看清再谈规模。Agent 基础设施的复杂度应该是被业务逼出来的而不是被技术焦虑逼出来的。我在实际操作中最深的一个体会是Agent 的真正瓶颈从来不是模型本身而是数据的质量和基础设施的韧性。一个数据管道混乱的团队换再强的模型也救不回来而把数据分级、记忆分层、反馈闭环这三件事做好哪怕模型不是最强的Agent 的整体表现也不会差。大家如果正在做或准备做 Agent 相关的项目不妨先停下来把数据这条线理清楚再往前跑——这个投入一定值得。
