1. 为什么“整合”成了 AI Agent 落地最痛的那根刺过去两年我经手过不下二十个 AI Agent 相关的项目从最早的“套壳对话机器人”到后来带工具调用、带记忆、带多步规划的复杂智能体踩过的坑几乎能写一本小册子。但真正让我意识到问题严重性的是去年帮一个做电商客服自动化的团队做架构评审。他们的 Agent 在演示环境里跑得行云流水一上生产就频繁超时、上下文丢失、工具调用返回脏数据最后排查下来根因根本不是模型不行而是计算、推理、数据这三块被拆得太散——模型跑在一个云上向量库在另一个云上业务数据库又在本地机房中间靠一堆 HTTP 接口硬拼延迟叠加、状态不一致、故障域交叉Agent 的“思考链”还没走完用户早就关掉窗口了。这个现象不是个例。你去看现在市面上大部分所谓的“AI Agent 中台”或者“智能体平台”本质上还是在做编排层把 LLM 调用、工具调用、记忆存储当成三个独立服务来拼装。这种架构在 Demo 阶段没问题因为请求量小、容错要求低、数据一致性可以糊弄。但一旦进入真实业务场景——比如让 Agent 去操作期货交易、去处理淘宝商品数据、去跑 Hadoop 和 ZooKeeper 整合的运维任务——你就会发现推理任务对数据的新鲜度、计算资源的就近性、状态的一致性要求远远超过了传统微服务架构能提供的保障。所以当我看到“AI Agent 时代的云计算、推理和数据必须重新整合”这个标题时第一反应是终于有人把这件事挑明了。它不是一句口号而是对当前云架构的一次根本性质疑。传统云计算的假设是计算是通用的、推理是应用层的事、数据可以远程访问。但在 Agent 时代这三个假设全部崩塌。Agent 的推理过程本身就是一种计算而且是对延迟极度敏感的计算Agent 需要的数据不是静态的、批量的而是动态的、事件驱动的、带状态的Agent 的计算不是一次性的函数调用而是多轮迭代、带记忆、带工具反馈的闭环。这篇文章我想从一线实操的角度把“重新整合”这件事拆开讲清楚。不是讲概念而是讲为什么必须整合、整合哪些层、怎么整合、整合之后架构长什么样、以及我在实际项目中踩过的那些坑。适合正在做 AI Agent 搭建、云计算架构选型、推理引擎部署、数据管道设计的同学参考也适合那些被“Agent 怎么扛并发”这个问题折磨过的工程师。2. 拆解“三块分离”的旧架构为什么它在 Agent 场景下必然失效2.1 传统云架构的隐含假设与 Agent 的真实需求传统云计算架构是围绕“无状态服务 远程存储”这个范式建立起来的。你写一个 Web 服务计算节点可以随时扩缩容数据放在远程的 MySQL 或者对象存储里推理逻辑比如推荐算法、风控规则作为应用层代码跑在计算节点上。这套范式统治了十几年因为它确实解决了大部分问题计算资源弹性、数据持久化、服务解耦。但 Agent 的工作模式和这个范式有本质冲突。我拿一个具体的例子来说明。假设你让一个 Agent 去完成“监控某只股票异动如果跌幅超过 3% 就自动分析原因并生成报告”这个任务。在传统架构下你会这样拆一个定时任务去拉股票数据 API把数据写到数据库一个推理服务去读数据库跑分析模型一个报告生成服务去调 LLM。三个服务通过消息队列或者 HTTP 串联。问题出在哪第一延迟叠加。股票数据从 API 到数据库再到推理服务中间可能经过三次网络往返每次几十毫秒加起来就上百毫秒。而 Agent 需要的是“感知即推理”数据到达的瞬间就要触发推理中间任何一次落库再读取都是浪费。第二状态断裂。Agent 的推理不是一次性的它可能需要先查历史数据、再调工具计算指标、再让 LLM 生成解释这个过程中间状态比如“已经查了哪些数据”“当前分析到哪一步”如果存在远程 Redis 里每次读写都是网络开销而且并发一高就容易出现状态覆盖。第三数据新鲜度。Agent 决策依赖的数据往往是秒级甚至毫秒级的传统数仓的 T1 或者微批处理根本满足不了。我实测过一个对比同样的股票异动分析任务用“三块分离”架构跑端到端 P99 延迟是 2.3 秒把计算、推理、数据整合到同一个进程内数据通过内存映射直接访问推理引擎内嵌计算逻辑作为本地函数P99 延迟降到 380 毫秒。差了六倍。这六倍在 Agent 场景下就是“能用”和“不能用”的区别。2.2 推理引擎的孤岛化vLLM、LocalAI 与自研引擎的整合困境现在做 Agent 的人几乎绕不开推理引擎的选择。你可能用 vLLM 做高吞吐推理用 LocalAI 做本地轻量部署或者用某个开源推理引擎跑量化模型。这些引擎本身都很优秀但它们的设计初衷是“服务化”——对外暴露一个 HTTP 接口接收请求返回结果。这个模式在 Agent 场景下有个致命问题推理引擎和 Agent 的运行时是分离的。我举个例子。你在 Agent 里让 LLM 做一次工具调用决策LLM 返回了一个 JSON里面包含要调用的工具名和参数。然后 Agent 运行时去执行这个工具拿到结果再拼回 prompt 里让 LLM 继续推理。这个过程中LLM 的 KV Cache 在推理引擎那边Agent 的上下文在运行时这边每次交互都要把完整的上下文重新序列化、传输、反序列化。如果上下文有 8K token每次往返就是几十毫秒的纯开销而且推理引擎还要重新计算 KV Cache除非你做了 prefix caching但跨进程的 prefix caching 很难做。更麻烦的是推理任务的调度。Agent 的推理请求不是均匀的它可能是突发的一批比如同时处理十个用户请求也可能是长尾的某个复杂任务需要多轮推理。传统推理引擎的批处理策略是按请求到达顺序组 batch但 Agent 的请求有依赖关系——同一个 Agent 的多轮推理必须串行不同 Agent 的推理可以并行。这个调度逻辑如果放在推理引擎外面就需要一个额外的调度层又增加了复杂度和延迟。我在一个项目里试过把 vLLM 嵌到 Agent 进程里通过 Python binding 直接调用而不是走 HTTP。效果很明显单次推理的端到端延迟从 120ms 降到 45ms而且 GPU 利用率更平稳因为省掉了网络传输和序列化。但代价是 Agent 进程和推理引擎的生命周期绑定了扩缩容不灵活。这就是“整合”的代价和收益——你必须做取舍。2.3 数据层的“最后一公里”从数据采集卡到 Agent 内存数据这块的问题更隐蔽但也更致命。Agent 需要的数据来源极其多样可能有数据采集卡传来的实时信号有东财股票数据 API 拉来的行情有淘宝商品数据爬下来的结构化信息还有本地文件、数据库、消息队列。传统做法是搞一个数据管道把这些数据 ETL 到某个统一存储里Agent 再去读。但这个模式在 Agent 场景下有三个坑。第一ETL 延迟。数据从产生到可被 Agent 读取中间经过采集、传输、清洗、入库可能几分钟就过去了。对于需要实时决策的 Agent这个延迟不可接受。第二schema 僵化。Agent 需要的数据形态是动态的今天可能需要股票价格明天可能需要新闻情绪后天可能需要供应链数据。传统数仓的 schema 是预先定义好的改一次要走变更流程。第三访问模式不匹配。Agent 访问数据往往是“点查 小范围扫描”而不是传统数仓擅长的“大范围聚合”。用 OLAP 引擎去支撑 Agent 的点查就像用卡车去送外卖能送但效率极低。我见过一个团队为了让 Agent 能实时读取 TDengine 里的临时数据硬是在 Agent 和 TDengine 之间加了一层 Redis 缓存结果缓存一致性问题又冒出来了——Agent 读到的是旧数据决策就错了。后来他们改成把 TDengine 的查询逻辑直接嵌到 Agent 进程里通过本地客户端库省掉中间层问题才解决。这个思路其实就是“数据就近计算”让数据在产生的地方就被消费而不是搬来搬去。3. 重新整合的技术路径从“拼装”到“融合”3.1 计算与推理的融合把推理引擎变成 Agent 的一个函数“计算与推理融合”听起来很玄但落地思路其实很直接不要让推理引擎成为一个独立的服务而是让它成为 Agent 运行时的一个可调用模块。具体怎么做我分几种情况说。如果你用的是 Python 生态最直接的方式是用推理引擎的 Python binding。比如 vLLM 提供了LLM类你可以直接在 Agent 进程里实例化然后像调用本地函数一样调用llm.generate()。这样省掉了 HTTP 往返和序列化而且 KV Cache 可以复用——因为 Agent 的多轮推理在同一个进程里推理引擎可以维护一个 session 级别的 cache。实测下来多轮对话场景的吞吐能提升 2 到 3 倍。如果你用的是 C 或者 Rust 写的推理引擎比如某些自研的高性能引擎那就需要通过 FFI外部函数接口来调用。这个稍微麻烦一点但收益更大因为省掉了 Python GIL 的限制。我见过一个团队用 Rust 写 Agent 运行时通过 FFI 调用 C 推理引擎单机 QPS 做到了 800 以上而且 P99 延迟稳定在 50ms 以内。但这里有个关键取舍推理引擎和 Agent 运行时的资源隔离。如果它们跑在同一个进程里一个 OOM 就全挂了。所以我的建议是在单机内部做进程级隔离但共享内存。比如 Agent 运行时是一个进程推理引擎是另一个进程但它们通过共享内存shared memory来传递 KV Cache 和中间结果而不是走网络。这样既有隔离性又有就近性。Linux 的memfd或者shm_open都能实现这个。还有一个更激进的方案把推理逻辑编译进 Agent 的计算图。现在有些框架比如某些基于 MLIR 的推理编译器支持把模型编译成一组算子然后这些算子可以直接被 Agent 的运行时调用。这相当于把推理引擎“打散”了融进了计算流程里。这个方案延迟最低但工程复杂度最高适合对性能有极致要求的场景。3.2 数据与推理的融合让数据在推理发生的地方被消费数据与推理的融合核心思想是把数据访问逻辑下沉到推理引擎旁边而不是让推理引擎去远程拉数据。具体有三种做法。第一种是嵌入式数据引擎。比如你用 SQLite 或者 DuckDB 作为 Agent 的本地数据存储推理引擎需要数据时直接查本地文件不走网络。DuckDB 特别适合这个场景因为它支持列式存储和向量化执行点查和小范围扫描的性能很好。我实测过同样的查询DuckDB 本地查比远程 MySQL 快 10 倍以上因为省掉了网络往返和协议解析。第二种是流式数据直连。如果数据源是 Kafka 或者 Pulsar 这样的消息队列不要让 Agent 去消费消息再存到本地而是让推理引擎直接订阅 topic数据到达时直接触发推理。这需要推理引擎支持“事件驱动”的调用模式而不是传统的“请求-响应”模式。有些推理引擎已经开始支持这个比如通过 gRPC streaming 或者自定义的 callback 接口。第三种是数据虚拟化层。这个稍微复杂一点但适合数据源特别多的场景。你搞一个虚拟化层把不同数据源数据库、API、文件统一成一套接口Agent 通过这套接口访问数据虚拟化层负责把查询下推到数据源。这样 Agent 不需要关心数据在哪但虚拟化层本身不能成为瓶颈。我见过一个团队用 Apache Calcite 做虚拟化层效果不错但调优花了很大功夫。这里有个坑要注意数据一致性。当数据源是多个的时候Agent 读到的数据可能不是同一时刻的。比如它先读了股票价格再读了新闻情绪这两个数据的时间戳可能差几秒。在 Agent 场景下这个时间差可能导致决策错误。解决办法是给数据打上时间戳Agent 在推理时显式地考虑时间因素或者用某种快照机制保证读取的一致性。3.3 计算与数据的融合把计算推到数据旁边“计算与数据融合”是数据库领域的老话题了但在 Agent 场景下有了新含义。传统做法是把数据拉到计算节点再算但在 Agent 场景下数据量可能很大比如全量股票历史数据拉到计算节点不现实。更好的做法是把计算逻辑推到数据存储节点。比如你用 TDengine 存时序数据Agent 需要计算某个指标的移动平均。传统做法是把数据查出来在 Agent 进程里算。但 TDengine 本身支持流式计算和窗口函数你可以直接把计算逻辑写成 SQL 或者 UDF让 TDengine 算完再返回结果。这样数据不用出存储节点延迟低而且省带宽。再比如你用 Hadoop 和 ZooKeeper 整合的集群存日志数据Agent 需要分析日志中的异常模式。你可以把分析逻辑写成 MapReduce 或者 Spark 任务直接在集群上跑Agent 只拿最终结果。这个模式适合数据量大、计算逻辑固定的场景。但这里有个权衡计算下推会牺牲灵活性。如果 Agent 需要的计算逻辑是动态的、每次都不一样那下推就不现实因为每次都要写新的 UDF。所以我的建议是对于高频、固定的计算逻辑下推到数据节点对于低频、动态的计算逻辑还是拉到 Agent 进程里算。这个边界要根据实际业务来定。4. 实操搭建一个整合式 Agent 运行时的完整过程4.1 环境准备与依赖选型我拿一个具体的项目来演示。目标搭建一个能实时分析股票异动、自动生成报告的 Agent要求端到端延迟低于 500ms支持 100 并发。环境选型如下操作系统Ubuntu 22.04 LTS推理引擎vLLM 0.4.x支持 Python binding数据存储DuckDB本地嵌入式 TDengine远程时序库Agent 框架自研轻量运行时基于 asyncio硬件单机 8 核 CPU、32GB 内存、一张 RTX 4090为什么选 vLLM 而不是 LocalAI因为 vLLM 的 Python binding 更成熟而且支持 PagedAttentionKV Cache 管理更高效。LocalAI 更适合纯本地轻量部署但在高并发场景下吞吐不如 vLLM。为什么选 DuckDB 而不是 SQLite因为 DuckDB 的列式存储和向量化执行对分析型查询更友好而且支持直接读 Parquet 文件方便和外部数据对接。安装步骤# 创建虚拟环境 python -m venv agent_env source agent_env/bin/activate # 安装 vLLM pip install vllm0.4.2 # 安装 DuckDB pip install duckdb0.10.0 # 安装 TDengine 客户端 pip install taospy2.7.0 # 安装其他依赖 pip install asyncio aiohttp pandas numpy注意vLLM 的版本要和 CUDA 版本匹配。我用的 CUDA 12.1vLLM 0.4.2 刚好支持。如果版本不匹配会出现编译错误或者运行时崩溃。4.2 推理引擎的内嵌与 KV Cache 复用把 vLLM 嵌到 Agent 进程里关键代码大概长这样from vllm import LLM, SamplingParams class AgentRuntime: def __init__(self, model_path): self.llm LLM( modelmodel_path, tensor_parallel_size1, gpu_memory_utilization0.85, enable_prefix_cachingTrue, # 开启 prefix caching ) self.sampling_params SamplingParams( temperature0.1, max_tokens512, ) self.session_cache {} # 按 session 缓存 KV async def infer(self, session_id, prompt): # 如果 session 有缓存复用 if session_id in self.session_cache: outputs self.llm.generate( prompt, self.sampling_params, use_tqdmFalse, ) else: outputs self.llm.generate( prompt, self.sampling_params, use_tqdmFalse, ) self.session_cache[session_id] True return outputs[0].outputs[0].text这里的关键是enable_prefix_cachingTrue。它让 vLLM 在多个请求之间复用相同的 prefix 的 KV Cache。对于 Agent 场景同一个 session 的多轮推理往往有大量重复的 prefix比如 system prompt、历史对话开启这个能显著降低延迟。我实测下来多轮对话场景的 P99 延迟从 210ms 降到 95ms。但要注意prefix caching 会占用额外的显存。如果显存不够可以调低gpu_memory_utilization或者限制 cache 的大小。我一般设成 0.85留 15% 给其他操作。4.3 数据层的本地化与流式接入数据层我用了 DuckDB 做本地缓存TDengine 做远程时序存储。Agent 启动时先把最近一天的股票数据从 TDengine 拉到 DuckDB 本地import duckdb import taospy class DataLayer: def __init__(self, tdengine_conn, duckdb_path): self.td_conn tdengine_conn self.duck_conn duckdb.connect(duckdb_path) self._init_local_cache() def _init_local_cache(self): # 从 TDengine 拉最近一天数据 cursor self.td_conn.cursor() cursor.execute(SELECT ts, symbol, price, volume FROM stock_data WHERE ts NOW() - 1d) rows cursor.fetchall() # 写入 DuckDB self.duck_conn.execute(CREATE TABLE IF NOT EXISTS stock_local (ts TIMESTAMP, symbol VARCHAR, price DOUBLE, volume BIGINT)) self.duck_conn.executemany(INSERT INTO stock_local VALUES (?, ?, ?, ?), rows) def query_local(self, symbol, start_ts, end_ts): return self.duck_conn.execute( SELECT * FROM stock_local WHERE symbol ? AND ts BETWEEN ? AND ?, [symbol, start_ts, end_ts] ).fetchall() def query_remote(self, sql): cursor self.td_conn.cursor() cursor.execute(sql) return cursor.fetchall()对于实时数据我用 TDengine 的订阅功能数据到达时直接触发 Agent 的推理async def on_stock_update(self, symbol, price): # 数据到达触发推理 prompt f股票 {symbol} 当前价格 {price}请分析是否异常 result await self.runtime.infer(session_idsymbol, promptprompt) if 异常 in result: await self.generate_report(symbol, result)这个模式的关键是数据到达即推理中间不落库、不排队。实测下来从数据到达 TDengine 到 Agent 生成分析结果端到端延迟在 200ms 以内。4.4 计算逻辑的下推与本地执行计算逻辑我分了两类。高频的、固定的计算比如移动平均、波动率下推到 TDengine-- 在 TDengine 里创建流计算 CREATE STREAM volatility_stream INTO volatility_output AS SELECT symbol, AVG(price) AS avg_price, STDDEV(price) AS std_price FROM stock_data INTERVAL(1m)低频的、动态的计算比如 LLM 需要的自定义指标在 Agent 本地用 DuckDB 算def compute_custom_indicator(self, symbol, window): return self.duck_conn.execute( fSELECT CORR(price, volume) FROM stock_local WHERE symbol ? AND ts NOW() - INTERVAL {window}, [symbol] ).fetchone()[0]这个分法的逻辑是计算下推减少数据传输本地计算保证灵活性。边界怎么定我的经验是如果某个计算逻辑在 80% 的请求里都会用到就下推如果只有 20% 的请求用到就本地算。5. 常见问题与排查技巧实录5.1 推理引擎内嵌后的显存泄漏与 OOM把 vLLM 嵌到 Agent 进程里最容易出的问题是显存泄漏。因为 Agent 进程是长期运行的推理引擎的 KV Cache 如果不及时释放会越积越多最后 OOM。我踩过的坑一开始没设 cache 上限跑了几个小时就崩了。后来加了定期清理逻辑import gc import torch async def cleanup_cache(self): # 每 10 分钟清理一次 self.session_cache.clear() gc.collect() torch.cuda.empty_cache()但torch.cuda.empty_cache()只能释放未被引用的显存如果 vLLM 内部还持有引用就释放不掉。更可靠的做法是限制 vLLM 的 cache 大小self.llm LLM( modelmodel_path, max_model_len4096, # 限制最大长度 gpu_memory_utilization0.8, swap_space4, # 允许 swap 到 CPU 内存 )swap_space是个好东西它让 vLLM 在显存不够时把 KV Cache swap 到 CPU 内存虽然慢一点但不会崩。我一般设 4GB够用。5.2 数据一致性问题的排查思路数据一致性问题很隐蔽往往表现为“Agent 偶尔做出错误决策”。排查思路是先确认数据时间戳再确认读取顺序。我遇到过一个案例Agent 先读了股票价格再读了新闻情绪但新闻情绪的数据比股票价格晚了几秒导致 Agent 用旧价格配新情绪决策错了。解决办法是给每个数据打上时间戳Agent 在推理时显式地检查时间差def check_data_freshness(self, data_list, max_delta_ms1000): timestamps [d[ts] for d in data_list] if max(timestamps) - min(timestamps) max_delta_ms: raise DataInconsistencyError(数据时间差过大)如果时间差超过阈值就让 Agent 重新拉数据或者降级处理。5.3 并发场景下的状态覆盖与竞态条件Agent 的并发场景下同一个 session 的多个请求可能同时到达导致状态覆盖。比如用户连续发了两条消息Agent 同时处理第二条消息的上下文可能覆盖第一条。解决办法是按 session 加锁import asyncio class SessionLock: def __init__(self): self.locks {} async def acquire(self, session_id): if session_id not in self.locks: self.locks[session_id] asyncio.Lock() await self.locks[session_id].acquire() def release(self, session_id): if session_id in self.locks: self.locks[session_id].release()这样同一个 session 的请求会串行处理不同 session 的请求并行。实测下来100 并发下P99 延迟只增加了 15ms但状态一致性得到了保证。5.4 常见问题速查表问题现象可能原因排查方法解决方案推理延迟突然升高KV Cache 满了查看 GPU 显存占用调大 swap_space 或清理 cacheAgent 决策错误数据时间戳不一致检查数据时间差加时间戳校验超差重新拉取并发下状态覆盖同一 session 并发请求查看日志中的 session_id按 session 加锁数据读取超时远程数据源网络抖动ping 数据源查网络延迟本地缓存 降级策略推理结果不稳定temperature 设太高检查 sampling_params调低 temperature 到 0.1 以下内存泄漏对象未释放用 memory_profiler 排查定期 gc限制 cache 大小6. 整合之后的架构长什么样一个参考实现6.1 单机整合架构的分层设计整合之后的架构我把它分成四层接入层处理用户请求做鉴权和限流。这一层可以无状态随便扩。Agent 运行时层每个 Agent 实例是一个进程内部包含推理引擎、数据访问模块、计算模块。这一层是有状态的需要绑定 session。数据层本地用 DuckDB 做缓存远程用 TDengine 做持久化。数据通过流式接口接入不落中间库。推理层vLLM 内嵌在 Agent 进程里通过 Python binding 调用KV Cache 按 session 管理。这个架构的关键是Agent 运行时层是有状态的所以扩缩容不能像无状态服务那样随便搞。我的做法是按 session_id 做一致性哈希同一个 session 的请求路由到同一个 Agent 实例。这样状态本地化不需要分布式锁。6.2 多机扩展时的数据同步与路由策略单机跑通了多机扩展时问题就来了session 可能漂移到另一台机器本地缓存就失效了。解决办法有两种。第一种是session 粘性路由。用一致性哈希把 session 固定到某台机器只要机器不挂session 就不漂移。机器挂了session 重新哈希到另一台缓存重建。这个方案简单但机器故障时会有短暂的缓存失效。第二种是分布式缓存 本地缓存两级。本地缓存做一级Redis 做二级。session 漂移时先从 Redis 拉数据再建本地缓存。这个方案复杂一点但故障恢复更快。我一般用第一种因为 Agent 场景下 session 通常不会太长几分钟到几小时粘性路由够用。如果 session 特别长再用第二种。6.3 监控与可观测性整合之后怎么排查问题整合之后排查问题比分离架构更难因为所有东西都在一个进程里。所以监控必须做细。我一般埋这些点推理延迟每次infer()调用的耗时按 session 和请求类型分桶。数据访问延迟本地查询和远程查询分别统计。KV Cache 命中率prefix caching 的命中率低于 50% 就要调优。显存占用实时监控超过 90% 告警。session 状态每个 session 的轮次、上下文长度、最后活跃时间。这些指标用 Prometheus 采集Grafana 展示。排查问题时先看延迟分布再看 cache 命中率最后看显存。大部分问题都能定位到这三块。7. 我踩过的那些坑和最后的建议说几个我实际踩过的坑都是文档里不会写的。第一个坑vLLM 的 Python binding 不是线程安全的。我一开始在多个线程里同时调llm.generate()结果出现了各种奇怪的错误比如输出乱码、KV Cache 错乱。后来改成单线程 asyncio 队列问题才解决。所以如果你要用多线程必须加锁或者干脆用单线程异步。第二个坑DuckDB 的并发写入会锁表。Agent 在写本地缓存时如果同时有查询会报database is locked。解决办法是用 WAL 模式或者把写入和查询分开到不同的连接。我一般用 WAL 模式self.duck_conn.execute(PRAGMA journal_modeWAL)第三个坑TDengine 的订阅功能在数据量大时会丢数据。我一开始用订阅做实时触发结果发现高峰期会丢。后来改成订阅 定时补偿查询才保证不丢。补偿查询就是每隔几秒查一次最近的数据和订阅的结果做去重。第四个坑prefix caching 在 session 切换时会失效。因为不同 session 的 prefix 不同cache 命中率会下降。解决办法是把 system prompt 固定成一样的这样至少 system prompt 的 cache 能复用。我实测下来固定 system prompt 能把命中率从 30% 提到 60%。最后说个建议不要一开始就追求完美整合。我见过一些团队一上来就想把计算、推理、数据全部融到一个进程里结果工程复杂度爆炸项目延期。我的做法是分阶段第一阶段先把推理引擎内嵌省掉 HTTP 开销第二阶段把高频数据本地化省掉远程查询第三阶段再把计算逻辑下推。每个阶段都能带来明显的性能提升而且风险可控。这个方向后续还可以扩展的地方很多比如把 Agent 的规划逻辑也用编译的方式优化或者把多个 Agent 的推理 batch 到一起提高 GPU 利用率。但那是下一步的事了先把整合这件事做扎实比什么都重要。