1. Agent 时代的基础设施到底在变什么1.1 从“模型为中心”到“数据与执行环境为中心”的转向过去两年绝大多数团队做 AI 应用的路径都差不多选一个能力最强的模型把提示词打磨到极致然后接一个向量库做检索就算完成了一个“智能应用”。这条路在 Demo 阶段非常有效但一旦进入真实业务问题就集中爆发了——模型回答不稳定、工具调用失败、长任务跑到一半断掉、上下文越堆越乱、成本失控。我在几个实际项目里反复踩过这些坑之后逐渐意识到一件事Agent 的瓶颈从来不在模型本身而在模型之外的那一整套数据与执行基础设施。这个判断不是拍脑袋得出的。你可以把 Agent 想象成一个刚入职的实习生他的智商模型能力可能已经很高但他能不能把活干好取决于三件事——他能不能拿到准确、及时、结构化的资料数据层他有没有一套靠谱的工具和操作台执行层以及他做完一步之后能不能记住、复盘、继续往下走状态与记忆层。这三件事恰好就是“数据与 AI 基础设施”要解决的问题。所以当标题里出现“数据·智能·进化”这三个词时我理解它描述的其实是一条演进链路数据是原料智能是加工能力进化是这套系统在真实反馈中持续变好的机制。Agent 时代的基础设施本质上就是让这条链路能够稳定、可观测、可迭代地跑起来。1.2 为什么现在必须重新审视基础设施有几个现实变化逼着我们必须重新设计这套东西。第一任务从“一问一答”变成了“多步执行”。以前调用一次模型就结束现在一个 Agent 任务可能包含检索、规划、调用工具、校验结果、再规划动辄十几步甚至几十步。每一步都可能失败每一步都消耗 token每一步都产生中间状态。没有基础设施支撑这种任务根本没法稳定运行。第二数据从“静态知识库”变成了“动态上下文”。RAG 时代我们习惯把文档切块塞进向量库但 Agent 需要的数据往往带有时间戳、权限、来源可信度、版本信息。同一份数据在不同任务里的可见性和新鲜度要求完全不同简单的向量检索已经不够用了。第三系统从“单次调用”变成了“长期运行的服务”。Agent 要能记住上一次交互、要能从中断处恢复、要能被人工介入纠正。这就对状态管理、日志追踪、沙盒隔离提出了工程级的要求。我见过太多团队把 80% 的精力花在调提示词上结果上线后 90% 的问题都出在数据管道断裂、工具调用超时、状态丢失这些“基础设施”层面。这个比例本身就是最好的说明。2. 数据层Agent 的“粮草”该怎么管2.1 数据采集与接入的常见坑Agent 要干活首先得有数据。但“有数据”和“数据能用”是两回事。我在实际项目里总结下来数据接入环节最容易出问题的地方有三个。第一个坑是数据源异构且不稳定。一个稍复杂的 Agent 往往要同时对接数据库、对象存储、第三方 API、内部文档系统。这些数据源的响应格式、超时行为、限流策略各不相同。我做过一个项目Agent 需要同时查订单库和调用外部物流接口结果外部接口偶尔返回 200 但 body 是空的Agent 直接把空数据当成“没有物流信息”回复给用户造成了不小的客诉。后来我们在接入层加了一层数据校验与降级逻辑任何外部数据进来先做 schema 校验校验失败就走缓存或明确报错绝不让脏数据流进推理环节。第二个坑是数据新鲜度与一致性。很多团队用离线批处理把数据同步到向量库同步周期可能是小时级甚至天级。但 Agent 面对的用户问题往往是“刚刚”“现在”这种实时性要求很高的场景。我的做法是分层处理对时效性要求极高的数据走实时查询接口对变化不频繁的知识类数据走向量检索并在检索结果里明确标注数据的时间戳和来源让模型自己判断这份数据是否还适用。第三个坑是权限与隔离。这个问题在多租户或企业内部 Agent 里特别致命。如果检索层不做权限过滤A 部门的 Agent 可能检索到 B 部门的敏感数据。我的经验是把权限控制下沉到数据接入层而不是指望在提示词里告诉模型“不要泄露”。提示词是软约束权限过滤是硬约束两者必须都有但硬约束才是底线。2.2 数据加工从原始数据到 Agent 可用的上下文原始数据接入之后不能直接丢给模型。中间需要一个加工层我通常把它拆成四步。清洗与标准化把不同来源的数据统一成一致的格式。比如时间统一成 ISO 格式金额统一带上币种文本统一去掉多余空白和乱码。这一步看起来琐碎但能极大降低模型理解成本。切分与结构化不是所有数据都适合切块。结构化数据表格、JSON应该保留结构用 schema 描述给模型非结构化文本才需要切块而且切块策略要结合内容类型——技术文档按标题层级切对话记录按轮次切代码按函数切。我试过用统一的固定长度切块结果把一段完整的操作步骤从中间切断模型拿到半截信息直接给出了错误答案。元数据标注这是最容易被忽略但价值最高的一步。给每个数据块打上来源、时间、类型、可信度、权限标签等元数据Agent 在检索时就能做更精细的过滤和排序。比如同样是“价格”信息来自官方定价页的数据可信度应该高于来自论坛讨论的数据。向量化与索引最后才是 embedding 和建索引。这里有个经验不要只用一种 embedding 模型。不同语言、不同领域的数据用同一个模型效果差异很大。我通常会对中英文混合数据做一次语言检测分别用适合的模型处理检索时再合并结果。2.3 数据质量监控让问题在爆发前被发现数据层最怕的不是“没有数据”而是“数据悄悄变坏了没人知道”。我建议至少建立三个监控指标。监控维度具体指标告警阈值建议完整性空值率、字段缺失率单字段缺失率 5%时效性数据延迟、同步失败次数延迟超过 SLA 的 2 倍一致性跨源数据冲突率冲突率 1%这些指标不需要一开始就做得很复杂哪怕先用脚本每天跑一次统计把结果发到群里都能提前发现很多问题。我在一个项目里就是靠一个简单的“空值率日报”发现上游某个数据源悄悄改了字段名导致连续三天检索结果质量下降。3. 智能层Agent 的编排与执行该怎么设计3.1 Agent 框架选型的核心考量现在 Agent 框架非常多从轻量的编排库到完整的平台都有。选型时我一般看四个维度。控制粒度有些框架把规划、执行、反思都封装好了上手快但不好改有些框架只提供基础的工具调用和循环控制灵活但需要自己写很多逻辑。我的建议是先用封装度高的框架快速验证验证通过后再逐步下沉到可控粒度。一上来就追求完全自研往往会在还没验证需求的时候就耗尽精力。状态管理能力Agent 执行到一半中断了怎么办能不能从断点恢复中间状态存在哪里这些问题在 Demo 阶段不重要但上线后就是生死线。我倾向于选择状态可持久化、可查询、可回放的框架哪怕它其他方面弱一点。工具生态框架自带多少工具适配、接入自定义工具的成本有多高。这里有个细节工具的输入输出 schema 是否强制校验。我见过因为工具返回格式和声明不一致导致 Agent 陷入死循环的案例后来强制所有工具走 schema 校验才解决。可观测性能不能看到每一步的输入输出、耗时、token 消耗、失败原因。没有这个排查问题基本靠猜。3.2 任务编排把复杂任务拆成可管理的步骤Agent 处理复杂任务时最忌讳的就是“让模型一口气想完所有步骤”。我的做法是显式地把任务拆成阶段每个阶段有明确的输入、输出和成功标准。一个典型的任务编排可能长这样意图理解阶段解析用户请求明确目标、约束、可用工具。信息收集阶段调用检索和工具收集完成任务所需的数据。规划阶段基于收集到的信息生成执行计划计划要具体到每一步调用什么工具、传什么参数。执行阶段逐步执行计划每步执行后校验结果是否符合预期。校验与修正阶段检查最终结果是否满足用户要求不满足则回到规划或执行阶段。这里的关键是每个阶段之间要有明确的交接物而不是靠模型在上下文里“记着”。比如规划阶段的输出应该是一个结构化的计划对象执行阶段只认这个对象不认自然语言描述。这样做的好处是每一步都可测试、可替换、可回放。3.3 工具调用Agent 与真实世界交互的接口工具调用是 Agent 最容易出问题的环节。我总结了几条实操经验。工具描述要精确到参数级别。不要写“查询订单信息”而要写“根据订单号查询订单详情输入为订单号字符串输出包含状态、金额、时间的对象”。模型对工具的理解完全依赖描述描述模糊就会乱传参数。工具要有超时和重试策略。外部工具调用失败是常态不能让 Agent 卡死在一个工具上。我通常设置单次调用超时 10 秒失败重试 2 次重试仍失败则返回明确的错误信息让 Agent 决定下一步。工具返回结果要精简。很多工具返回一大堆字段全塞进上下文会迅速耗尽 token。我的做法是在工具层做一次过滤只返回 Agent 当前任务需要的字段其余字段放在可查询的存储里需要时再取。危险操作要加确认机制。删除数据、发送消息、执行支付这类操作必须有人工确认或二次校验不能完全交给 Agent 自主决定。这不是不信任模型而是工程上必须有的安全边界。3.4 记忆与状态让 Agent 不再“失忆”Agent 的记忆我一般分三层来设计。短期记忆当前任务的上下文包括对话历史、中间结果、工具返回。这层通常放在上下文窗口里但要有裁剪策略不能无限增长。我的做法是保留最近 N 轮完整内容更早的内容做摘要压缩。长期记忆跨任务的知识和偏好。比如用户的常用地址、历史操作习惯、领域知识。这层通常存在外部存储里通过检索按需加载。这里要注意写入长期记忆要有筛选不能什么都记否则记忆库会迅速被噪音淹没。状态快照任务执行到关键节点时保存完整状态支持中断恢复和回放。这层对调试特别有价值我经常用状态快照来复现线上问题。4. 进化层让系统在运行中持续变好4.1 反馈闭环从“能用”到“越用越好”Agent 系统上线只是开始真正决定它价值的是能不能持续进化。进化的核心是建立反馈闭环。反馈来源主要有三个用户显式反馈点赞、点踩、修正、系统隐式信号任务成功率、工具调用失败率、用户中断率、人工评估定期抽样检查输出质量。这三类反馈要统一收集、统一存储并且能关联到具体的任务轨迹上。我见过很多团队收集了反馈但不知道怎么用。我的做法是把反馈转化为可执行的改进项如果是提示词问题就改提示词如果是工具问题就修工具如果是数据问题就补数据如果是模型能力问题就考虑换模型或加微调。关键是每条反馈都要有归属不能收集完就放着。4.2 评估体系没有评估就没有进化Agent 的评估比传统模型评估难得多因为输出是开放式的而且和任务强相关。我通常建三层评估。单元级评估针对单个工具调用、单次检索、单步推理做评估。这层可以用自动化测试覆盖比如给定输入检查工具是否被正确调用、参数是否正确。任务级评估针对完整任务做端到端评估。这层需要定义成功标准可以是规则判断比如订单是否真的创建成功也可以是模型辅助判断用另一个模型评估输出质量。业务级评估看 Agent 对业务指标的实际影响比如客服场景的解决率、研发场景的代码采纳率。这层周期长但最能说明问题。评估集要持续维护把线上发现的 bad case 不断补充进去这样评估集才能反映真实分布。4.3 迭代节奏小步快跑还是大版本更新我的经验是小步快跑更适合 Agent 系统。因为 Agent 的行为受很多因素影响一次改太多东西出了问题根本不知道是哪个改动导致的。具体做法是每次只改一个变量提示词、工具、数据源、模型改完在评估集上跑一遍确认没有回退再上线。上线后观察线上指标稳定后再进行下一个改动。这个过程听起来慢但比“大版本更新后一堆问题一起爆发”要快得多。另外要建立回滚机制。Agent 系统的配置提示词、工具定义、模型版本应该版本化管理出问题能一键回滚到上一个稳定版本。我在一个项目里就是因为没有回滚机制一次提示词改动导致线上任务成功率从 85% 掉到 40%花了半天才定位到问题。5. 实操中的常见问题与排查技巧5.1 任务执行中断与恢复现象Agent 执行长任务时突然中断日志显示“execution terminated due to error”。排查思路先看是模型调用失败、工具调用失败还是状态存储失败。模型调用失败通常是超时或限流工具调用失败要看具体工具的错误码状态存储失败往往是序列化问题或存储容量问题。解决经验我给所有关键步骤加了 checkpoint每完成一步就保存状态。中断后可以从最近的 checkpoint 恢复而不是从头再来。这个机制在长任务场景下能省大量时间和 token。5.2 工具调用参数错误现象Agent 调用工具时传了错误参数比如把字符串传成了数字或者漏传了必填字段。排查思路检查工具 schema 定义是否清晰检查模型是否理解了参数含义检查是否有示例引导。解决经验在工具描述里加 few-shot 示例非常有效。比如“查询订单”工具给一个“输入订单号 12345输出{...}”的示例模型传参准确率会明显提升。另外工具层要做参数校验不合法直接返回明确错误让 Agent 有机会修正。5.3 上下文膨胀导致成本失控现象任务越跑越慢token 消耗远超预期。排查思路统计每步的上下文长度找出增长最快的部分。通常是工具返回结果太大、历史消息没裁剪、检索结果塞太多。解决经验工具返回做字段过滤历史消息做摘要压缩检索结果限制条数并做相关性排序。我一般会把单次任务的上下文控制在模型窗口的 60% 以内留出余量给推理和输出。5.4 常见问题速查表问题类型典型表现优先排查方向常用解决手段任务中断执行到一半停止状态存储、超时设置加 checkpoint、调超时工具失败调用返回错误工具 schema、网络、权限校验参数、加重试、查权限输出质量差答非所问、遗漏信息检索质量、提示词、上下文改检索策略、优化提示词成本过高token 消耗大上下文长度、调用次数裁剪上下文、合并调用响应慢延迟高模型选择、串行调用换小模型、并行化6. 我对这套基础设施的一点个人体会做了几个 Agent 项目之后我最大的体会是不要试图一步到位建一套完美的基础设施。我见过团队花三个月设计了一套“终极架构”结果需求一变全部推倒重来。更务实的做法是从最小可用版本开始哪里疼治哪里。具体来说第一版只需要保证数据能进来、工具能调用、状态能保存这三件事。跑起来之后你会发现真正的瓶颈往往和你预想的不一样。可能是某个数据源特别不稳定可能是某个工具特别慢可能是模型在某个环节特别容易出错。针对这些真实瓶颈去补基础设施比提前设计一堆用不上的能力要高效得多。另一个体会是可观测性要尽早做。Agent 系统的问题往往很隐蔽没有详细的日志和追踪排查起来就是大海捞针。我现在的习惯是项目第一天就把每一步的输入输出、耗时、token 消耗记录下来哪怕一开始只是写文件后面再换成正式的追踪系统。这个投入在后期排查问题时能十倍百倍地回报回来。最后分享一个小技巧给 Agent 加一个“解释模式”。在调试阶段让 Agent 在每一步输出它的思考过程和依据虽然会增加 token 消耗但对理解 Agent 为什么做出某个决策极其有帮助。等系统稳定后再关掉这个模式成本和可调试性就能兼顾。