1. 项目概述为什么我们需要将“中间产物”提升为一等公民在构建智能体系统时我们常常陷入一个效率陷阱系统花费大量计算资源生成一个中间结果比如一次复杂的数据库查询结果、一段经过推理生成的文本草稿、或者一个临时的数据转换表但一旦这个结果被下游步骤消费它就像用完即弃的草稿纸被丢弃在内存的角落最终被垃圾回收。下次遇到类似甚至相同的任务时系统又得从头再来一遍重复计算消耗宝贵的算力和时间。这听起来是不是很熟悉尤其是在处理复杂、多步骤的Agent工作流时这种浪费尤为明显。“Intermediate Artifacts as First-Class Citizens”这个理念正是为了解决这个核心痛点。它主张将智能体系统中产生的中间产物从临时的、易失的“二等公民”状态提升为与输入、输出同等重要的“一等公民”。这意味着我们需要为这些中间产物建立一个正式的、持久化的数据模型让它们能够被存储、索引、检索、复用甚至作为知识资产进行版本管理和依赖分析。简单来说就是把每次Agent思考过程中产生的“草稿”和“半成品”都当成有价值的“零部件”或“中间件”保存下来形成一个可复用的知识库。这个想法并非凭空而来。随着大模型驱动的智能体系统从简单的单轮对话演进到处理复杂业务流程、软件开发、数据分析等需要多步骤、长周期协作的场景中间状态的持久化和复用需求变得前所未有的强烈。一个数据分析Agent可能需要多次查询和清洗数据一个代码生成Agent可能需要反复调试和修改函数片段。如果每次调用都从零开始不仅响应慢成本高而且Agent也无法从历史“工作记忆”中学习导致行为不一致或重复犯错。因此为中间产物建立一套“数据模型”使其成为系统架构中的核心组成部分是提升Agentic Systems效率、可靠性和可解释性的关键一步。2. 核心概念解析什么是“一等公民”与“持久化中间产物”要深入理解这个项目我们首先得拆解两个核心术语“一等公民”和“持久化中间产物”。这不仅仅是语义游戏而是设计哲学的根本转变。2.1 “一等公民”在系统设计中的含义在编程语言和系统设计领域“一等公民”通常指某个实体如函数、对象享有最基本的权利例如可以被赋值给变量、可以作为参数传递给函数、可以作为函数的返回值、可以包含在数据结构中。赋予中间产物“一等公民”地位意味着我们在设计智能体系统时需要给予它们同等的“权利”独立的身份标识每个中间产物都应该有一个全局唯一的ID就像数据库里的一条记录有主键一样。这允许我们精确地引用它。可序列化与持久化它必须能够被完整地转换成一种格式如JSON、Protocol Buffers、或自定义的二进制格式并存储到磁盘或数据库中而不是只存在于内存中。可检索与可查询系统需要提供机制能够根据内容、元数据、生成上下文等条件高效地检索到已有的中间产物。具备丰富的元数据除了内容本身它还应携带“上下文护照”包括生成它的Agent ID、任务ID、父级产物ID、生成时间戳、消耗的Token数、使用的模型版本、置信度分数等。支持版本与依赖关系中间产物可能会被修改或衍生出新的版本。系统需要能管理这些版本并记录产物之间的依赖关系例如产物B是基于产物A生成的。当一个中间产物具备了这些特性它就不再是流程中一个默默无闻的过客而是一个可以被管理、复用和审计的正式资产。2.2 “持久化中间产物”的类型与形态那么在一个典型的Agentic System中哪些东西可以成为这种“一等公民”的中间产物呢范围其实非常广规划与分解结果Agent将复杂任务分解成的子任务列表、思维链Chain-of-Thought的步骤、决策树的分支。工具调用与结果调用外部API如搜索引擎、数据库、计算工具的请求参数和返回的原始结果。例如一次SQL查询语句和查询到的数据集。内容草稿与片段生成文本过程中的多个版本、代码生成中的函数雏形、设计草图的多轮迭代。上下文与记忆摘要从长对话或文档中提取的关键信息摘要、用户偏好画像的临时更新。验证与评估结果对某个输出进行的代码测试结果、事实核查的结论、质量评估的分数。这些产物形态各异但共同点是它们都包含了任务执行过程中的“工作状态”和“部分答案”具有潜在的复用价值。2.3 持久化 vs. 传统缓存本质区别你可能会问这听起来不就是高级缓存吗确实有相似之处但有本质区别。传统缓存如Redis通常是键值对关注的是快速存取键的设计相对简单通常是URL或参数哈希缓存策略如TTL也比较通用且不关心内容的结构和语义。而持久化中间产物的数据模型其核心在于 **“语义丰富性”**和“过程关联性”。语义索引我们可能需要根据产物的自然语言内容进行向量相似度检索而不仅仅是精确匹配一个键。过程上下文产物紧密绑定于生成它的具体任务、Agent和 workflow 实例。复用时不光是看结果对不对还要看“在什么情况下、由谁、为了什么目的”产生的这个结果。结构化存储产物可能具有复杂的嵌套结构如一个包含多个步骤的规划需要数据库支持灵活的模式如使用文档数据库MongoDB或PostgreSQL的JSONB字段。生命周期管理它的过期不是基于简单的时间而是可能基于任务流的完成状态、产物的“新鲜度”评分、或依赖关系的变更。因此我们需要的是一个专门为Agent工作流定制的、兼具缓存速度和知识库深度的存储与检索系统。3. 数据模型设计构建中间产物的“身份证”与“档案袋”设计一个能承载“一等公民”中间产物的数据模型是整个系统的基石。这个模型需要平衡灵活性、查询效率和信息丰富度。下面是一个我经过多个项目实践后总结出的核心模型设计它包含几个关键实体。3.1 核心数据实体定义我们可以设计一个以Artifact为核心的数据模型它通常包含以下字段{ artifact_id: uuid_v4_or_ulid, content: {...}, // 结构化或非结构化的内容主体 content_type: sql_result/json/plan/text/code, content_hash: sha256_of_content, // 用于去重和完整性校验 metadata: { task_id: uuid, workflow_id: uuid, step_id: string, agent_id: string, model_used: gpt-4-turbo, input_snapshot: {...}, // 触发生成此产物的输入快照 generation_parameters: {temperature: 0.7, max_tokens: 1000}, token_usage: {prompt: 500, completion: 300}, confidence_score: 0.85, generated_at: 2023-10-27T10:30:00Z }, relationships: { parent_artifact_ids: [uuid1, uuid2], child_artifact_ids: [uuid3], derived_from: uuid4 // 明确衍生关系 }, tags: [data_analysis, intermediate, user_query_123], storage_info: { location: s3://bucket/path/artifact.json, format: json, compressed: true }, ttl: 2023-10-28T10:30:00Z, // 可选的生存时间比缓存更灵活 access_control: {owner: agent_x, read_roles: [agent_y]} }设计要点解析artifact_id: 使用UUID或ULID确保全局唯一且可按时间粗略排序。content: 这是核心。为了支持灵活查询建议将关键信息同时以扁平化字段存储。例如如果content是SQL结果可以额外存储result_summary如行数、关键列值和vector_embedding用于语义检索。content_hash: 极其重要。用于内容去重。如果系统内产生了一个内容哈希完全相同的产物可以直接引用旧的避免存储和计算浪费。metadata: 这是产物的“上下文护照”。input_snapshot字段尤其关键它记录了生成此产物时的精确输入状态是判断一个旧产物是否适用于新场景的关键依据。relationships: 显式记录依赖关系这对于理解工作流、调试问题以及当上游产物更新时判断下游产物是否失效类似构建系统的增量编译至关重要。3.2 元数据的设计哲学与取舍元数据字段不是越多越好需要根据实际查询需求来设计。一个常见的误区是试图记录一切导致存储膨胀和写入性能下降。我的经验是区分热数据与冷数据高频查询的字段如task_id,agent_id,generated_at,content_type应作为数据库表的独立列或索引字段。低频查询的详细信息可以打包存入一个JSON字段如metadata中的generation_parameters。预计算检索键如果经常需要根据内容语义检索必须在写入时同步计算内容的向量嵌入embedding并存入专门的向量数据库或支持向量检索的字段中。快照的粒度input_snapshot应该保存什么保存完整的原始输入可能很大。一个折中方案是保存输入的指纹如哈希以及关键参数的提取值。或者对于确定性的工具调用如带参数的API调用保存参数即可。3.3 存储后端选型没有银弹只有权衡没有一种数据库能完美满足所有需求。通常需要组合使用主存储元数据与关系PostgreSQL是绝佳选择。它的JSONB类型能灵活存储metadata和content如果结构不固定同时支持强大的关系查询、事务和ACID特性非常适合管理产物之间的关系和复杂查询。使用它的pgvector扩展还能处理向量检索。向量存储语义检索当需要根据内容语义“模糊”查找相似中间产物时需要专门的向量数据库。Pinecone、Weaviate、Qdrant或Milvus都是成熟选项。它们能高效处理高维向量的近似最近邻搜索。内容存储大对象如果content非常大如图片、长文档可以将其存储在对象存储如AWS S3、MinIO或文件系统中而在PostgreSQL里只存引用路径storage_info.location。缓存层加速读取对于热点产物依然可以用Redis作为一层缓存但缓存的不再是原始响应而是序列化后的完整Artifact对象。实操心得混合存储架构在实际项目中我通常采用PostgreSQL pgvector S3的组合。PostgreSQL作为唯一可信源管理所有元数据、关系和中小型内容。pgvector处理语义搜索。S3存放大型内容。通过一个服务层来封装这些细节对上层应用提供统一的save_artifact和query_artifactsAPI。这样既保证了数据一致性又兼顾了性能和成本。4. 系统集成与工作流改造让Agent“学会”利用历史有了数据模型和存储下一步是如何将其无缝集成到现有的Agentic Systems中。这需要对Agent的执行引擎和工作流框架进行改造。4.1 在Agent循环中插入持久化钩子我们需要在Agent的标准推理循环感知-规划-执行-反思的关键节点插入钩子Hooks自动完成产物的捕获。规划后当Agent将任务分解为子任务列表Plan后立即将此Plan作为一个Artifact持久化content_type设为plan。工具调用前后调用前将工具调用的参数和上下文作为input_snapshot的一部分。调用后将工具的原始返回结果作为一个artifact持久化content_type设为tool_result并建立与本次调用参数产物的父子关系。生成内容后无论是LLM生成的文本草稿、代码片段还是其他输出都将其保存。对于多轮生成可以保存多个版本并记录版本链。反思或验证后将自我批评、事实核查的结果也作为产物保存content_type设为evaluation。这些钩子应该对Agent逻辑透明最好通过框架层面的中间件Middleware或装饰器Decorator来实现避免污染核心业务逻辑。4.2 检索与复用策略何时以及如何“偷懒”持久化的核心目的是复用。我们需要一套策略来决定当Agent需要执行某个步骤时是先计算还是先尝试从“历史仓库”里找一个可用的中间产物检索阶段精确匹配计算当前步骤输入的哈希值查找是否有input_snapshot哈希完全匹配的产物。这适用于确定性操作如相同的SQL查询。语义匹配将当前步骤的输入或目标描述转换为向量在向量存储中搜索最相似的artifact。这适用于非确定性或目标相似的场景如“总结一下这篇文章”和“概括这份文档的核心”。元数据过滤结合task_id,agent_id,content_type等缩小范围。匹配度评估阶段找到候选产物后不能直接使用需要评估其“适用性”。新鲜度产物是否太旧相关外部数据源是否已更新可以为产物附加一个数据源版本戳。置信度当初生成这个产物时Agent的confidence_score高吗上下文一致性当前任务上下文与产物生成时的上下文差异大吗可以通过比较关键的metadata字段来判断。决策与适配阶段如果找到匹配度高且新鲜的产物直接复用跳过该步骤的计算大幅节省时间和成本。如果找到相关但不完全匹配的产物可以将其作为“提示”或“起点”提供给LLM让LLM在此基础上修改或完善而不是从零开始。这被称为“检索增强生成RAG for intermediate artifacts”。如果没找到或匹配度太低则执行常规计算流程并在完成后持久化新产物。4.3 改造示例一个数据分析Agent的工作流假设一个数据分析Agent的工作流是1) 理解用户问题 - 2) 生成SQL - 3) 执行SQL - 4) 分析结果 - 5) 生成报告。改造前每次用户问类似问题Agent都完整走完这五步。改造后步骤2前Agent尝试检索。如果用户问“本月销售额”系统发现三天前有另一个用户问过“本月销售情况”并且生成了一个高度相似的SQLcontent_hash匹配或语义相似且数据源未更新则直接复用步骤2的SQL产物。步骤3前Agent尝试检索。如果找到了完全相同的SQL查询产物及其对应的结果产物且结果新鲜则直接复用步骤3的查询结果。步骤4前Agent尝试检索。如果找到了相同数据结果的分析结论产物且分析框架metadata中的分析模型版本未变则可能复用或参考该结论。通过这种方式工作流可能从 2-3-4 简化为 2复用-3复用-4部分复用效率提升立竿见影。5. 实践挑战与解决方案实录将理论付诸实践总会遇到各种坑。下面是我在实施这类系统时遇到的一些典型挑战及解决办法。5.1 挑战一产物定义的粒度与爆炸问题问题应该把多细粒度的东西当作一个独立产物是把整个“规划”作为一个产物还是把规划的每一步都作为一个产物粒度太粗复用不灵活粒度太细产物数量爆炸管理复杂检索开销大。解决方案采用分层产物模型。定义两种或三种粒度的产物Coarse-grained Artifact对应一个完整的子任务或阶段输出如“数据查询阶段产物”包含SQL和结果。Fine-grained Artifact对应一个原子操作如“SQL生成产物”、“SQL执行结果产物”。 系统同时保存两种。检索时先尝试粗粒度匹配如果匹配成功且适用则直接复用整个阶段如果不完全适用则下钻查看其包含的细粒度产物看是否有部分可用。这需要在relationships中明确记录这种包含关系。5.2 挑战二检索效率与准确性之间的平衡问题向量检索虽然灵活但计算开销大且可能返回语义相关但逻辑不适用的结果例如“分析销售额”和“预测销售额”语义相近但一个是分析过去一个是预测未来产物不能混用。解决方案混合检索策略 重排序。第一层快速过滤。使用content_type,agent_id,task_family等强约束在关系型数据库中进行快速筛选大幅缩小候选集。第二层语义搜索。对筛选后的候选集使用向量检索进行语义相似度排序。第三层规则/模型重排序。对Top-K的语义相似结果使用一组轻量级规则或一个小型判别模型结合metadata中的上下文信息如时间范围、参数差异进行最终打分和排序确保返回的结果在逻辑上可用。5.3 挑战三产物的失效与更新传播问题外部世界在变化。一个基于“上周用户数据”生成的中间产物在本周数据更新后就失效了。更复杂的是如果产物A被复用并产生了新产物B当A失效时B是否也应该标记为失效或需要重新计算解决方案依赖追踪与失效标记。在产物的metadata中记录其依赖的外部数据版本号如数据库快照ID、API数据更新时间戳。建立一个后台进程定期或在外部数据更新时触发扫描依赖了旧版本数据的产物将其状态标记为stale陈旧。对于产物依赖链通过relationships.derived_from记录可以采用类似“脏标记”的方法。当某个基础产物被标记为stale时可以递归地标记所有直接或间接依赖它的下游产物为stale。当下次查询到stale产物时系统可以选择自动触发重新计算或返回结果但附带“此结果基于可能过时的数据”的警告。5.4 挑战四存储成本与生命周期管理问题如果无限制地保存所有中间产物存储成本会快速增长。很多产物可能再也没有被访问过。解决方案智能的生命周期策略。基于价值的保留为产物定义“价值分数”基于其被复用的次数、节省的计算成本Token数、生成它的成本、关联任务的重要性等因素动态计算。定期清理低价值分数的旧产物。分层存储高频访问的热产物留在高性能数据库如PostgreSQL中。低频访问的冷产物可以归档到更便宜的存储如S3 Glacier。元数据始终保留在数据库中以便检索当需要时再从归档中恢复内容。任务上下文关联清理当一个长期任务如一个多日项目最终完成或关闭时可以一次性清理该项目产生的所有中间产物除非其中某些被标记为“知识资产”需要长期保留。6. 衡量收益与效果评估投入精力构建这样一套复杂的机制必须能看到实实在在的收益。我们可以从以下几个维度来衡量计算成本节省这是最直接的指标。统计因复用中间产物而跳过的LLM调用、工具调用的次数和Token消耗。可以计算“复用率”复用的步骤数 / 总步骤数和“成本节省百分比”。延迟降低比较复用路径和全新计算路径的端到端延迟。工具调用如数据库查询、API调用和长文本生成通常是延迟大户复用它们能显著提升用户体验。系统一致性提升对于相同或相似的输入系统因为复用而给出更一致的输出减少了LLM随机性带来的波动这对于用户体验和调试都有好处。可观测性与可调试性增强所有中间步骤都被持久化这为调试复杂的Agent工作流提供了前所未有的便利。可以像查看日志一样回溯整个任务执行过程查看每个产物的输入输出精准定位问题所在。知识积累系统运行越久中间产物库越丰富相当于系统在自动构建一个领域特定的“过程知识库”。新任务可以从中汲取经验甚至可能涌现出跨任务的知识复用模式。实施初期建议选择一个特定的、高频率的Agent工作流进行试点详细记录上述指标的前后对比。用数据来证明价值是推动项目进一步扩展的最佳方式。在我自己的实践中为一个客户服务对话分析系统引入中间产物持久化后对于常见的报表类查询步骤复用率达到了40%以上平均响应时间减少了35%LLM的Token消耗降低了近30%。更重要的是当业务人员询问“为什么这个数字是这样得出的”时我们可以清晰地展示出从原始问题到SQL生成再到数据计算每一步的中间产物极大地增强了系统的可信度和透明度。将中间产物视为一等公民不仅仅是一个技术优化更是一种思维模式的转变。它要求我们从设计之初就将智能体系统的“思考过程”也作为有价值的数据资产来管理。这条路开始走起来可能会觉得有些复杂增加了架构的维度但一旦跑通它所带来的效率红利、成本优势和系统可维护性的提升将是决定性的。尤其是在Agent需要处理越来越复杂、越来越长期任务的未来这种“记住过去所做工作”的能力会成为智能体系统是否成熟、是否高效的关键标志。