说个得罪人的大实话：在隔离内网里做 AI Agent，和在公网环境完全不是一回事。公网环境下那些"调个 API、写两段 prompt 就能跑"的玩法，放到隔离内网里每一步都会被卡脖子——模型服务不在线、依赖装不上、数据出不去、并发一上来就雪崩。这半年我一直在这类环境里折腾，从零搭了一套真正面向业务落地的 Agent 系统，踩过的坑比写过的代码还多。
这篇文章不是教你怎么写 prompt，而是把我从需求分析、架构设计、技术选型到并发改造、故障排查的完整过程摊开来讲。重点说清楚隔离内网下 AI Agent 工程化要过的几道坎，以及每道坎具体怎么过。适合内网信息化团队、私有化部署实施人员，还有所有准备在受限网络环境里把 Agent"下地干活"的人阅读。看完你至少能避开我踩过的那大半坑。
1. 先想清楚：隔离内网里做 Agent，到底难在哪
1.1 你面对的不是 AI 问题，而是工程环境问题
很多人拿到需求第一反应是"选个模型、接个框架、开写"，但在隔离内网里，最先跳出来打脸的往往是环境本身。我归纳了一下，隔离内网至少给你设了四道关卡：
网络隔离。办公网和业务网之间有一道看不见的墙，服务器没有公网出口，更不可能直接访问任何外部大模型 API。所有模型推理能力必须落在一台你摸得着的内网服务器上，要么自己部署推理服务，要么接入公司已有的算力平台。这个过程会遇到大量模型服务怎么暴露、鉴权怎么做、多业务线怎么共享的问题。
依赖受限。pip、npm、maven 这些包管理工具默认走公网源，在内网环境里十有八九是连不上的。你写好的 Agent 代码如果用到 LangGraph、FastAPI、向量库客户端，就必须提前准备好内网镜像源或者离线 wheel 包。我见过不止一个团队，代码都写完了，结果部署时依赖装不上，被迫推翻重来。
数据敏感。内网系统里的数据往往是不能出网的，prompt 也好、工具调用结果也好、向量化后的文档内容也好，全部在内网闭环里流转。这意味着你不能偷懒去用公网 embedding API，得自己部署 embedding 模型，向量库也得搭在内网。
运维通道有限。没有便捷的云端监控和日志平台，所有可观测性建设都得自己搭。出了问题，能靠的就只有内网日志、内网监控面板和团队成员的经验。
这四道关卡决定了你的技术选型：凡是依赖公网 SaaS 的方案，一律砍掉；凡是需要在离线环境里自托管的组件，尽早规划。这个判断在整个项目里是最高优先级的，后面所有决策都建立在它之上。
1.2 两条架构路线：单机嵌入 与 服务中台
我见过隔离内网里的 Agent 架构，基本可以归成两派。
单机嵌入型，是最常见的起步形态。把模型推理服务（比如一份 Ollama 或者 vLLM 进程）和 Agent 代码放在同一台机器上，模型API地址直接写成 127.0.0.1，所有任务在这台机器内闭环。优点是部署简单、调试方便、不需要跨网络协调，最适合做 PoC 或者单业务线的小工具。
服务化中台型，是把 Agent 能力拆成独立服务，供多个业务系统复用。模型推理服务独立部署，Agent 编排服务独立部署，中间通过公司内部 API 网关互相调用，再加上任务队列、向量数据库、统一的可观测性平台。优点是好扩展、好治理、不同业务线可以共用同一套 Agent 底座；缺点是前期投入大，网络拓扑复杂，需要运维配合。
我整理了一个对比，方便你根据自己团队的处境判断：
| 维度 | 单机嵌入型 | 服务化中台型 |
|---|---|---|
| 部署成本 | 低，一台上线 | 高，需多组件协作 |
| 扩展性 | 差，单机性能封顶 | 好，可横向扩容 |
| 多业务复用 | 难，各写各的 | 容易，能力统一沉淀 |
| 治理与审计 | 弱，难统一管控 | 强，可集中做工具权限、数据审计 |
| 适合阶段 | PoC、试点、工具型产品 | 正式业务系统、平台型产品 |
1.3 我的选择：服务化中台 + 受控工具
我们这个项目的业务是给内部运营人员提供"自然语言查询和任务代办"能力：运营同事在对话框里问一句"上个月华东区的退单率趋势怎么样"，Agent 自己去查数据平台、调报表工具、汇总结论再返回。这显然不是单机玩具能扛住的，所以我选了服务化中台路线。
但真正让我坚定这个选择的，是这个考量：Agent 的本质是"规划 + 调用工具"，而工具就是数据流入口。在隔离内网环境中，数据合规是死线，任何工具调用都必须可审计、可控制。服务化中台可以很自然地把所有 Agent 内部需要访问的数据接口集中收敛到一个"工具网关"后面，每次调用都有记录、有审批、有权限校验。单机嵌入型想做这件事，难度会翻好几倍。
另外一个很实际的原因是模型资源。内网里部署一个能用的推理服务不便宜，如果每个业务线都自己搞一份"单机模型"，GPU 资源浪费极其严重。中台化之后，模型推理服务可以被所有 Agent 任务共享，再配合请求排队和优先级控制，资源利用率能高出一大截。工程上的选择从来不是"哪个技术更酷"，而是"哪个方案在约束条件下更省心"。
2. 技术选型：把"能跑"变成"能交付"的关键决策
2.1 模型推理服务：内网一切能力的地基
隔离内网里，模型推理是整个 Agent 系统的动力源。没有模型服务，Agent 连"思考"都做不到。我这边最终选了基于 vLLM 搭建内网推理服务，用 OpenAI 兼容协议对外暴露。为什么是 vLLM 而不是别的？两个原因：第一，吞吐量高，用的是 PagedAttention 机制，显存利用更充分，同样的 GPU 能扛更多并发；第二，协议兼容性好，下游不管是 LangChain、LangGraph 还是自研代码，接一个 OpenAI 风格的 base_url 就能跑。
选模型参数量之前，先把显存账算清楚。这是最容易被忽略的一步。以 16bit 精度推理为例，7B 模型的权重约 14GB（70亿参数 × 2字节），加上 KV Cache 和激活值，单张 24GB 显存的卡能勉强跑；13B 模型权重约 26GB，单卡 24G 就放不下了，至少要 40GB 以上；70B 级别模型权重更是上百GB，通常要量化到 4bit/8bit 之后才能塞进单卡或者多卡并行。
实际项目里我选了 13B 量级的开源基座模型，配 4bit 量化，部署在两块 40GB 卡上。这样做的原因是：内部任务以"工具调用 + 结构化输出"为主，不需要太强的自由创作能力，13B 在指令遵循和 JSON 输出上已经够用；推理耗时要控制，同样一张卡，小模型响应快很多，用户体感完全不一样。这里给所有内网项目的建议是：先跑通最小验证，再根据业务数据调模型，千万别一开始就追大参数。
2.2 Agent 编排框架：LangGraph 与自研的取舍
Agent 编排层是系统的"大脑回路"。我的技术栈里原本备选方案有 LangChain、LangGraph、AutoGen，以及完全自研的状态机。LangChain 在早期尝试里被我去掉了，原因很朴素：它的抽象层级太多，调试链路长，出了 bug 经常要翻三层源码才能定位问题。相比之下，LangGraph 的"图编排 + 状态管理"设计更贴近 Agent 的真实运行逻辑——Agent 本质上就是一个有状态、多步骤的图执行过程。
LangGraph 的核心思路很好理解：你把 Agent 的思考过程拆成节点，比如"规划节点"、"工具执行节点"、"结果分析节点"，节点之间用边连接，通过条件判断决定下一步走向哪个节点。每一步都会更新一个全局状态对象，这个对象记录了任务目标、历史消息、工具返回结果等关键信息。
from langgraph.graph import StateGraph, END class AgentState(dict): messages: list tool_results: dict def plan_node(state): # 基于当前任务生成执行计划 ... return {"messages": plan_output} def act_node(state): # 调用一个或多个注册工具 ... return {"tool_results": outputs} def observe_node(state): # 汇总工具结果，判断是否需要继续执行 ... def should_continue(state): if state.get("need_more"): return "act" return END builder = StateGraph(AgentState) builder.add_node("plan", plan_node) builder.add_node("act", act_node) builder.add_node("observe", observe_node) builder.set_entry_point("plan") builder.add_edge("plan", "act") builder.add_edge("act", "observe") builder.add_conditional_edges("observe", should_continue, {"act": "act", END: END}) graph = builder.compile()但我也没全盘照搬 LangGraph，它在隔离内网里有一个现实问题：装依赖得走离线源，版本升级也要手动管理。于是我在 LangGraph 外面包了一层自己写的"运行环境适配层"，把依赖收敛到一个固定的版本组合里，统一打进内网镜像源。实际踩下来的感受是：框架选型不是一次性的，你要做好"用框架，但不被框架绑架"的准备。
2.3 内网依赖仓库与模型权重分发
这一节讲的不是 AI，但往往决定 AI 项目能不能顺利上线。我在项目初期就吃了大亏：代码在开发机上跑得好好的，一到内网服务器就报 ModuleNotFoundError，原因是服务器连不上公网 PyPI。
后来我建了一套内网包管理方案，基本分三层：
- Python 依赖库：在开发机上用
pip download把所有依赖的 wheel 包（包括传递依赖）全部下载下来，装到内网一台专门跑 Sonatype Nexus 的机器上，作为私有 PyPI 源。之后所有内网服务器统一通过pip install --index-url http://nexus.internal/repository/pypi/安装。 - 前端与系统包：同理，用 Nexus 代理 npm、apt 等源，按团队实际用到的包定期同步。
- 模型权重与 Embedding 模型：模型权重文件动辄几十 GB，不能走包管理，提前拷到内网规定的存储区，推理服务启动时按路径索引。这一步必须提前和运维沟通好存储配额和传输通道，否则等到了上线日才发现模型根本传不进去，就很被动了。
依赖管理是典型的"前期不愿意做、后期哭着补"的工程债。越是网络受限的环境，越要在项目第一天就把私有源方案定下来。
3. 核心模块实现：Agent 主循环、工具与 API 服务
3.1 Agent 主循环与工具注册机制
框架层选定之后，核心工作就落在了 Agent 的主循环和工具接入上。我们的实现思路是：Agent = 模型推理 + 工具注册表 + 记忆管理 + 循环控制。模型推理负责决策，工具注册表决定它能干什么，记忆管理决定它记不记得上下文，循环控制决定它什么时候停下来。
工具注册我设计成了一个装饰器模式，把工具定义和业务实现解耦：
TOOL_REGISTRY = {} def register_tool(name, description, parameters_schema): def decorator(func): TOOL_REGISTRY[name] = { "func": func, "description": description, "parameters_schema": parameters_schema, } return func return decorator @register_tool( name="query_order_stats", description="按日期范围查询订单统计摘要", parameters_schema={ "type": "object", "properties": { "start_date": {"type": "string"}, "end_date": {"type": "string"}, }, "required": ["start_date", "end_date"], }, ) def query_order_stats(start_date: str, end_date: str): # 内部统一走数据服务网关发查询请求 ... return json.dumps({"order_count": 128, "total_amount": "98210.50"})这个注册表的价值在于，Agent 每次决定调用工具时，都会先从注册表里拿到工具的描述和参数格式，填充模型返回的工具调用参数，再真正执行。参数错误、工具不存在、执行超时这些异常，全部可以在这一层统一兜住，而不是散落在各个业务函数里。
主循环最核心的控制逻辑是最大步数限制。Agent 跑飞是常态，尤其在没有网络约束的隔离内网里，模型一旦陷入"反复调用工具但拿不到有效结果"的死循环，会把系统拖垮。我给的默认值是 6 步，超过直接终止并返回当前已收集的信息。这个数字可以根据任务复杂度调，但一定得设上限。
3.2 记忆与上下文管理：防止 Agent"失忆"
隔离内网场景里，Agent 的上下文管理比公网场景更吃设计。原因是业务数据分散在多个内部系统，Agent 需要在多轮交互里不断把查到的事实带进对话，如果上下文管理不好，用户在第三轮问"我前面说的那个订单呢"，Agent 根本接不上话。
我实践下来比较顺手的是"三层记忆"方案：
- 短期对话记忆：用滑动窗口控制送进模型的历史消息数量，比如只保留最近 10 轮。窗口之外的对话不再参与推理，防止上下文过长导致模型注意力分散，也降低 Token 消耗。
- 阶段性摘要记忆：当对话轮次超过窗口上限时，用模型把旧对话压缩成一两句摘要，随新对话一起送入。这种"先摘要、后截断"的方式我在长表单填写场景里实测非常有效。
- 业务记忆：把用户在任务里沉淀的关键实体（客户名、订单号、日期范围）抽出来，存进内网向量库。Agent 在执行新任务时，按相似度检索相关业务记忆，作为背景知识注入 prompt。
向量库我们内网部署的是单机版 Milvus，文档量级在百万以内完全够用。你要特别留意的是 embedding 模型也得内网部署，否则向量化这一步就把数据送出网了。我用的是一个轻量级中文 embedding 模型，单卡 GPU 就能跑，batch 化处理之后，百万级文档建立索引大概只花了几小时。
3.3 用 FastAPI 封装对外服务
Agent 内部逻辑跑通之后，下一步是把它封装成业务系统可以调用的服务。我用 FastAPI 做这一层，最大的原因是异步原生成熟——Agent 任务里有大量 I/O 等待（模型推理、工具调用、向量检索），异步事件循环能最大化吞吐。
对外接口我设计了两个：一个是同步查询接口，适合快速问答；一个是异步任务接口，适合耗时的流程型任务。同步接口的核心代码长这样：
from fastapi import FastAPI, HTTPException from pydantic import BaseModel app = FastAPI(title="Internal Agent Service") class AgentRequest(BaseModel): query: str session_id: str = "default_session" timeout_seconds: int = 30 class AgentResponse(BaseModel): code: int = 0 message: str = "" data: dict | None = None @app.post("/agent/run", response_model=AgentResponse) async def run_agent(req: AgentRequest): try: result = await agent_runner.run( query=req.query, session_id=req.session_id, timeout=req.timeout_seconds, ) return AgentResponse(data=result) except TimeoutError: raise HTTPException(status_code=504, detail="Agent task timeout") except Exception as exc: # 统一兜底，避免框架异常直接暴露给调用方 raise HTTPException(status_code=500, detail=str(exc))流式输出也是内网场景的高频需求。运营同事问一个复杂的分析问题，如果必须等 Agent 全部跑完才能看到结果，等待体验会非常差。FastAPI 的StreamingResponse配合异步生成器，可以做到"模型每生成一个 token 就推送给前端"。实践下来，流式接口的心理等待时间比同步接口至少降低一半。
但流式输出对并发控制提出了更高要求，这就引出了下一章要讲的重点：并发和稳定性。
4. 并发与稳定性：隔离内网里怎么扛住流量
4.1 先算清楚你的并发瓶颈在哪
"AI Agent 怎么扛并发"这段关键词不是玄学，核心就一句话：瓶颈几乎永远在模型推理，而不在 Agent 业务代码。你在 FastAPI 里写一万个协程都没问题，可一旦超过模型服务的并发上限，所有请求都会排队，排队一长，超时、雪崩、用户体验崩坏，一样不少。
我给大家一个保守的容量估算公式。假设平均执行一次完整 Agent 任务需要T秒（包含模型推理和工具调用），业务要求每秒处理Q个请求，那么系统里至少需要能同时跑C = Q × T条任务。举个例子：一次报表查询任务平均耗时 8 秒，业务高峰期要求每秒处理 2 个请求，那你就需要至少 16 条并发任务的能力。这 16 条任务背后，模型推理服务至少要支持 16 路并发，如果单实例只能跑 4 路并发，你就得准备 4 个推理实例，或者接受排队。
内网场景经常有个错觉：我们用户量不大，不需要考虑并发。这个错觉会害死人。因为 Agent 任务是"耗时型"任务，不是普通 HTTP 接口那种毫秒级返回的"快速型"任务，哪怕同时只有 10 个人点了一下查询，也会瞬间堆积 80 秒的工作量。所以容量规划必须从第一天就做，否则系统一上线就会被流量打穿。
4.2 并发控制的三种手段
我在这套系统里用了三层并发控制，层层兜底。
第一层：模型推理服务的并发上限控制。vLLM 本身支持--max-num-seqs参数，限制同时处理的序列数量。剩下的请求会在模型服务内部排队。这个参数要根据显存和任务长度调，我这边设的是 8。超过这 8 路，模型进程不会崩，但延迟会显著上升。
第二层：Agent 服务层的信号量限流。用asyncio.Semaphore限制同时进入 Agent 主循环的任务数。比如推理服务能跑 8 路，我就把信号量设为 8，多余的请求直接走"排队等待"或"提示稍后再试"。这比让请求全部砸进模型层再排队要可控得多，因为你能在应用层直接给出友好提示，而不是让用户干等十几秒后超时。
from asyncio import Semaphore agent_semaphore = Semaphore(8) async def run_with_flow_control(query: str, session_id: str): async with agent_semaphore: return await agent_runner.run(query=query, session_id=session_id)第三层：任务队列异步化。对于耗时超过 20 秒的流程型任务，比如"批量生成周报并发送到指定邮箱"，同步等待已经不合适了。我在内部接了一个轻量任务队列，接口接收到请求后，把任务塞进队列立刻返回"任务已受理"，后端 Worker 再把任务从队列拉出来逐个执行。这一步直接解决了 HTTP 超时问题，也让系统在高峰期有了天然的缓冲。队列实现上用 Redis 的 Stream，或者直接接 Celery，按团队熟悉程度来就行。
4.3 重试、降级与幂等设计
稳定性不是只靠并发控制就能完成的。在隔离内网里，业务数据的波动性比公网 API 更大，工具调用常常遇到下游系统响应慢、返回格式不对、甚至临时不可用的情况。
重试机制里有一个关键教训：一定要区分任务类型。对于查询类任务，重试是安全的，哪怕同一个查询被执行两次，结果不变；对于写操作类任务，比如"创建工单""发送通知"，如果没有幂等设计，重试会造成重复数据。我的做法是：所有写操作工具在参数里强制要求一个request_id，下游系统按这个 ID 做去重。这样即使 Agent 因为超时重试了三次，下游也只会真正创建一条记录。
降级策略同样要提前想好。碰到模型推理服务过载时，我采取的是"限流熔断 + 友好提示"：返回一个标准的"系统繁忙"响应，而不是让用户看到一屏堆栈错误。碰到某个数据源系统宕机时，Agent 会把这个工具标记为不可用，然后在回答中明确告诉用户"订单数据服务暂不可用，建议联系数据中心"。让 Agent 学会说"我查不到"，比硬编一个错误码给用户要友好得多。
4.4 可观测性建设：没有监控，等于盲开
内网环境没有现成的 APM 服务，可观测性要自己搭。我用了最务实的三件套：结构化日志、Prometheus 指标、Grafana 看板。
结构化日志里有一个字段是必须的：链路 ID。每次请求进来，先生成一个 UUID，然后把这个 ID 贯穿 Agent 主循环的每一步——模型调用日志、工具调用日志、向量检索日志全部带上这个 ID。排查问题时，拿用户反馈的时间点，一顿 grep 就能把一次完整任务的所有执行细节拉出来。
指标监控我至少看五组数据：
- 请求量（按接口和业务线拆分）
- 任务平均耗时与 P95 耗时
- 模型 Token 消耗量
- 工具调用成功率与失败率
- 排队任务数与队列深度
指标口径上踩过一个坑：只看平均耗时会把问题掩盖掉。内网任务经常是多数简单任务秒回、少数复杂任务跑到 60 秒以上，平均值看起来还行，P95 已经高得离谱。所以我把 P95 和 P99 单独上了告警，阈值分别设为 15 秒和 30 秒，超过就往项目群发告警。这个习惯帮我提前发现了两次模型服务显存泄漏问题——P95 异常飙升比任何监控页面都能更快地暴露问题。
5. 常见问题与排查技巧实录
5.1 离线环境依赖装不上的自救手册
这是隔离内网项目里出现频率最高的一类问题。我的排查顺序是：先确认基础环境对不对，再确认包源配没配好，最后确认有没有编译依赖缺失。
一个很常见的坑是lxml、pydantic-core 这类带 Rust/C 扩展的包，在离线环境里没有预编译 wheel 时，会在安装时触发本地编译，而内网服务器又没有对应的 Rust 工具链和编译依赖，报错五花八门。解决办法是在开发机上用pip download --platform manylinux2014_x86_64 --python-version 3.11 --only-binary=:all:之类的方式，把所有依赖的二进制 wheel 下载齐，再传到内网私有源里。原则就是：只保留二进制 wheel，不在内网环境做源码编译。
Docker 是另一个离线分发利器。在开发机上把整个 Agent 运行环境打包成镜像，通过离线介质导入内网服务器的本地镜像仓库，依赖问题直接绕开。但注意镜像也得提前做好安全扫描和版本冻结，别让内网环境成为"随便 pull 镜像"的地方。
5.2 模型输出的"不可靠"怎么治
Agent 工程里最烦人的问题：模型不按格式输出。明明你在 prompt 里要求"只输出 JSON"，它偏要在前后加几句"好的，我来为您生成以下内容"。
我的处理分两层。第一层是"约束解码"，vLLM 支持引导模型按给定的 JSON Schema 生成，从解码阶段就限制输出结构，不是事后补救。这个方案在工具调用场景下能极大提升成功率。第二层是"宽松解析"，不管模型怎么输出，我先用正则把代码块、注释、多余前后缀去掉，再尝试json.loads，解析失败就触发一次带错误信息反馈的重试。重试 prompt 里明确说"上次输出 JSON 解析失败，请只输出 JSON"，这一招能救回不少翻车案例。
参数调优方面，我固定了这样一组：temperature=0.1、top_p=0.9、max_tokens=2048、repetition_penalty=1.05。temperature 压低是为了让工具调用和格式输出更稳定，但也不是越低越好，太低模型容易陷入机械重复；rep penalty 适度开启，能有效抑制长文本生成时的重复片段。每换一个模型基座，这组参数都要重新验证一遍，不能拿来就用。
5.3 上下文污染与串话问题
隔离内网系统通常不止一个业务线接入，Agent 一旦把 A 业务的上下文带到 B 业务的对话里，后果很严重。有个真实案例：运营人员在查 A 区订单时问了一句"顺便把上次那个方案也发我"，Agent 如果共享全局上下文，就可能把 B 区的方案摘要也带出来，这在数据合规上是不能接受的。
我做的第一件事是会话级隔离。每个 session 有独立的上下文存储，Agent 初始化时只从当前 session 加载历史。第二件事是工具结果截断。工具返回的数据动辄几十 KB，不能全量塞进上下文，既费 Token 又容易让模型迷失重点。我按工具类型做了定制化压缩：数据查询类的工具只保留聚合摘要和 top 10 明细；文档检索类的工具只保留命中片段；状态类的工具只保留关键字段值。第三件事是过期清理，session 超过 24 小时没有活跃，就把它的缓存和向量记忆清掉，避免内存里堆着大量僵尸会话。
5.4 并发上不去？先查这四个地方
我把后端同事问得最多的并发排查问题整理成了一张速查表，按以下顺序排查，基本能定位 80% 的瓶颈：
| 排查项 | 快速判断方法 | 常见根因 |
|---|---|---|
| 模型推理并发 | 看 vLLM 监控里的 seq 数，是否长期顶满 | --max-num-seqs配太小或显存不足 |
| 应用层信号量 | 看任务排队时间，是否大量任务等在 Semaphore 前 | 信号量数值和推理并发不匹配 |
| 下游工具接口 | 看工具调用耗时分布，是不是某个接口偶发 5 秒以上延迟 | 数据平台慢查询、无索引 |
| 数据库连接池 | 看报错里有无too many connections | 连接池上限小于任务并发数 |
遇到并发上不去的现象，先从这四张图开始拉数据，不要上来就猜。我发现很多"并发不行"的问题最终都落在下游工具接口上——Agent 代码优化得再好，一个数据中心接口在高峰期需要 3 秒才能返回，整个系统的吞吐就被按在地上摩擦。对这类慢接口，我的做法是给 Agent 工具层加本地缓存和超时熔断，把对下游的依赖降到最低。
最后说点实在的
这条链路跑顺之后，我很长时间里都在琢磨一个问题：隔离内网给 AI Agent 到底带来了障碍还是保护？客观说，障碍是真的——环境受限、依赖难装、数据闭环，每一步都比公网模式费劲。
但换一个角度想，也正是因为隔离内网的高约束，逼着我们把工程的底子打得更扎实：工具收敛成标准接口、上下文做成可追溯的会话、并发控制形成量化模型、监控指标落实到每一个请求。这套东西放到任何环境里都是通用的，反而比那些"公网一把梭、prompt 走天下"的方案更经得起压力测试。
最后再分享一个实用的小技巧：给 Agent 每次模型调用的 prompt 末尾加一行固定的输出指令，比如"如果工具调用结果为空，请明确回答暂无数据，不要编造"，这行指令在减少幻觉上的回报率，比调任何参数都明显。这个小改动是我们团队自测中效果最立竿见影的优化之一，你做 Agent 工程时不妨直接抄去试试。
