企业官网建设流程全解析

1. 为什么“七要素”和“七个决策点”是理解 Agent 工程落地的真正钥匙

很多人一听到 AI Agent，脑子里立刻浮现出“大模型+工具调用”的简单拼图——LLM 生成一段文字，再调用个天气 API，就叫 Agent 了。我最早做第一个生产级 Agent 项目时也是这么想的，结果上线第三天，用户反馈“它总在查天气，但我要的是订会议室”，运维告警里堆满了超时和重试日志，而日志里最刺眼的一行是：[INFO] Router: fallback to default path —— no tool match for intent 'book_meeting'。那一刻我才意识到，问题根本不在模型多大、工具多全，而在于整个系统里没有一个清晰、可干预、可调试的决策骨架。

市面上讲 Agent 的文章，90% 停留在概念层：“Agent 是能感知、规划、行动的智能体”；剩下 10% 落在框架层：“LangChain 支持 Tool Calling，LangGraph 支持 State Graph”。但没人告诉你，当一个用户输入“帮我把上周三销售数据导出成 Excel 发给张经理”，这句话在系统里要经历多少次隐式判断？它要先判断这是不是一次“数据操作”，再判断“上周三”属于时间解析范畴还是业务语义范畴，接着确认“销售数据”在哪个数据库、哪个表、哪些字段需要脱敏，然后决定是走预设 SQL 模板还是动态生成，最后还要校验张经理的邮箱是否在白名单、附件大小是否超限……这些判断，每一个都对应一个真实存在的代码分支、一个可配置的阈值、一个可能失败的环节。它们不是模型“自发涌现”的，而是工程师一条条写进去、一遍遍调出来的。

所谓“七要素”，不是教科书里的抽象定义，而是对一个真实运行中的 Agent 系统进行逆向解剖后，提炼出的七个不可绕过、必须显式设计的工程模块：目标锚定（Goal Anchoring）、上下文编织（Context Weaving）、意图识别（Intent Recognition）、工具路由（Tool Routing）、执行编排（Execution Orchestration）、状态快照（State Snapshotting）、反馈闭环（Feedback Loop）。它们共同构成 Agent 的“操作系统内核”。

而“七个决策点”，则是这七个模块在每次请求生命周期中，实际触发判断的具体位置与触发条件。比如“工具路由”这个要素，在真实代码里不会是一个叫route_tool()的函数，而是一连串嵌套判断：

• 第一决策点：当前 query 是否含明确工具关键词（如“查天气”“发邮件”）？
• 第二决策点：若无关键词，是否匹配预设业务意图模板（如“导出XX数据”→ 触发export_data工具）？
• 第三决策点：若模板不匹配，是否启用 LLM 进行零样本分类？此时需设定 confidence 阈值（如 0.85），低于则降级为通用问答；
• 第四决策点：若 LLM 分类成功，其返回的 tool_name 是否在白名单中？不在则拒绝执行并记录安全事件；
• ……

这七个决策点，每一个都对应着一行if/else、一个配置项、一次外部服务调用、一次日志埋点。它们才是你部署 Agent 时真正要填的坑、要压测的点、要监控的指标。本文接下来要做的，就是带你亲手拆开一个正在跑的 Agent 实例，逐行看透这七个要素如何落地为代码，七个决策点如何在毫秒级响应中完成判断链路。不讲虚的，只讲你明天就能改、能调、能上线的细节。

2. 七要素拆解：每个要素背后都藏着一个必须亲手写的模块

2.1 目标锚定（Goal Anchoring）：让 Agent 始终知道自己“为什么而活”

目标锚定不是给 Agent 设个“长期目标”这么浪漫。它是工程上最硬的约束：确保每一次交互都在一个明确、可终止、可验证的业务目标下进行。很多 Agent 上线后变成“话痨”，用户问一句“今天天气如何”，它回完天气又推荐旅游、又查航班、又问用户要不要订酒店——这不是智能，是失控。根源在于缺失目标锚定。

我们团队在金融客服 Agent 中强制实施了三层锚定机制：

• 会话级锚定（Session-Level Goal）：用户首次输入时，系统必须提取并固化一个核心目标。例如用户说“我想查上季度基金收益”，系统立即生成结构化目标对象：

  { "goal_id": "Q3_2024_fund_return", "primary_action": "query_fund_performance", "scope": ["fund_code", "quarter", "return_rate"], "exit_condition": "return a table with columns: fund_name, code, return_rate_q3" }

  这个对象被注入到整个会话的 state 中，后续所有 LLM 提示词（prompt）都强制包含Current Goal: ${goal_id}字段。我们实测发现，加了这一行，LLM 偏离目标的概率下降 67%。

• 步骤级锚定（Step-Level Goal）：当目标需多步完成（如“导出数据→发邮件→通知用户”），每一步必须有独立子目标。我们用 LangGraph 的StateGraph实现，每个节点（Node）的run()方法第一行就是校验state['current_step_goal']是否匹配。不匹配？直接抛异常中断流程，而不是让 LLM 自由发挥。

• 防御性锚定（Defensive Anchoring）：当用户中途插入新指令（如查完天气突然说“顺便订张机票”），系统不立即切换目标，而是触发goal_negotiation子流程：先确认“您是要暂停查天气，开始订机票吗？”，获得明确 yes/no 后才更新目标。这个逻辑写在 middleware 层，所有请求必经。上线后，因目标漂移导致的无效工具调用归零。

提示：目标锚定最大的坑是“过度抽象”。不要写“提升用户体验”这种目标，必须是“在 3 秒内返回用户指定日期的订单状态”。目标越具体，锚定越牢，LLM 越听话。

2.2 上下文编织（Context Weaving）：不是堆砌历史，而是构建可计算的语义图谱

多数人以为上下文就是把聊天记录拼起来喂给 LLM。错。真正的上下文编织，是把零散的对话、用户画像、业务规则、实时数据，转化为一张带权重、有时效、可查询的语义图谱。这张图谱不是给 LLM 看的，是给 Agent 的各个决策模块用的。

我们电商 Agent 的上下文图谱包含四个核心层：

• 对话层（Dialogue Layer）：存储最近 5 轮消息，但关键改造是：对每条用户消息做 NER（命名实体识别），标注entity_type: product_id, price_range, delivery_time。这些标签成为后续意图识别的强特征。
• 用户层（User Layer）：从 CRM 同步用户等级、历史投诉率、常用收货地址。特别重要的是preferred_communication_style字段（如“简洁型”“详细型”），它直接控制 LLM 输出长度和术语密度。
• 业务层（Business Layer）：硬编码的业务规则库。例如“满 299 包邮”不是写在 prompt 里，而是作为图谱中的一个rule_node，属性为{condition: "cart_total >= 299", action: "add_free_shipping"}。当用户说“我买够包邮了吗”，系统直接查图谱，不依赖 LLM 计算。
• 实时层（Real-time Layer）：接入库存服务、物流接口。当用户问“这个手机还有货吗”，系统优先查实时层节点stock_status_{sku_id}，命中则直接返回，不触发 LLM。

图谱的构建不是一次性动作。我们用 Redis Graph 存储，每次用户输入后，触发一个context_weaver服务：它解析新消息，更新对应节点属性，并计算各节点间的新关系权重（如用户连续三次问“发货时间”，则delivery_time节点对当前会话的权重 +0.3）。LLM 的 prompt 只接收图谱中权重 >0.5 的节点摘要，而非全部历史。实测下来，上下文 token 消耗降低 42%，而关键信息召回率提升至 99.2%。

2.3 意图识别（Intent Recognition）：为什么不能全靠 LLM 做分类？

意图识别常被简化为“让 LLM 给 query 打个标签”。但生产环境里，这招极不可靠。我们做过 A/B 测试：纯 LLM 分类 vs 混合分类（规则+小模型+LLM），在 10 万条真实客服 query 上，混合方案准确率 98.7%，纯 LLM 仅 83.4%。差距在哪？在于意图识别必须分层、可降级、可解释。

我们的七层意图识别流水线如下：

关键设计点：

• L1/L2 必须覆盖高频、确定性意图（如“查订单”“退钱”），它们处理了 73% 的请求，且永不失败；
• LLM 层（L4/L5）只处理长尾、模糊意图（如“那个东西怎么弄”），且强制限定输出格式为 JSON，避免自由文本；
• 所有层级共享同一套意图 schema，例如{"intent": "return_goods", "params": {"order_id": "xxx"}}，下游模块无需适配不同格式。

注意：别迷信“大模型更好”。在确定性高的业务场景，一个精准的正则比 GPT-4 更稳、更快、更便宜。我们的成本数据显示，L1/L2 处理 73% 请求，却只消耗 8% 的总计算资源。

2.4 工具路由（Tool Routing）：不是选工具，而是做一次带约束的决策树遍历

工具路由常被误解为“LLM 选个工具名”。但真实工程中，它是一次多约束条件下的决策树遍历，涉及权限、配额、SLA、数据合规等硬性限制。一个工具能否被调用，从来不只是“语义匹配”。

我们支付 Agent 的工具路由决策树包含七个强制检查点：

1. 权限检查（Permission Gate）：用户角色是否允许调用该工具？例如refund_tool仅对 VIP 用户开放，普通用户调用直接返回{"error": "insufficient_privilege"}。
2. 配额检查（Quota Gate）：今日退款次数是否超限？查 Redis 计数器user:{uid}:refund_count，超限则触发风控流程。
3. 数据范围检查（Scope Gate）：用户请求退款的订单，是否属于该用户本人？通过关联订单表与用户表校验order.user_id == current_user.id。
4. 金额阈值检查（Amount Gate）：退款金额是否超过单笔上限（如 5000 元）？超限需转人工审核。
5. 时间窗口检查（Time Gate）：订单创建时间是否在可退期内（如 7 天）？用order.created_at与当前时间比对。
6. 工具健康检查（Health Gate）：调用前 ping 支付网关健康接口，失败则降级至备用通道或返回错误。
7. 合规检查（Compliance Gate）：根据用户所在地区（从 IP 或 profile 获取），校验该笔退款是否符合当地金融监管要求（如欧盟需额外提供理由）。

只有全部检查通过，才进入最终的“语义匹配”环节——此时才让 LLM 从已过滤的工具池中选择。我们把这七个检查点封装为ToolRouter类的can_execute(tool, user, context)方法，每个检查点都是独立可插拔的模块。上线半年，因工具路由导致的资损事件为 0。

3. 七个决策点实战：从用户输入到工具执行的毫秒级判断链路

3.1 决策点一：Query 预清洗——在 LLM 看见之前，先做一次外科手术

用户输入永远是脏的。直接喂给 LLM，等于让医生看没消毒的伤口。我们的第一决策点，就是对原始 query 做无损清洗，目标是：保留语义完整性，剔除干扰噪声，标准化表达形式。

清洗流程分三步，全部在 LLM 调用前完成：

• 噪声剥离（Noise Stripping）：移除非语义字符。我们维护一个噪声词典，包含：

  • 输入法残留：“嗯...”、“啊？”、“那个...”
  • 平台特有符号：小红书的#话题、微信的【表情】
  • 语音转文字错误：“支付宝” → “支某宝”、“转账” → “装账”清洗后，“嗯...我想转#账#给张三【表情】” 变成 “我想转账给张三”。

• 指代消解（Coreference Resolution）：解决“它”“这个”“上次”等指代。我们不用复杂 NLP 模型，而是基于会话图谱做轻量级绑定。例如上一轮用户说“帮我查 iPhone 15 的价格”，本轮输入“它多少钱”，系统自动将“它”绑定到图谱中的product_id: "iPhone15"节点，query 更新为 “iPhone 15 多少钱”。

• 标准化（Normalization）：统一表达。例如：

  • 时间：“下周三” →{"type":"relative_date","offset":3,"unit":"day"}
  • 数字：“一千五” → “1500”
  • 单位：“KB” → “kb”（小写，统一单位制）

这个决策点的关键价值在于：它让 LLM 的输入变得高度结构化，大幅降低幻觉概率。我们对比测试显示，清洗后的 query，LLM 在数字、时间、专有名词上的错误率下降 58%。更重要的是，清洗日志成了绝佳的 bad case 分析源——所有清洗失败的 query 都进兜底队列，人工标注后反哺噪声词典，形成闭环。

3.2 决策点二：目标锚定触发——不是所有输入都值得启动一个 Agent

第二决策点，是判断“这个输入，是否真的需要启动一个完整的 Agent 流程？” 这是防止资源浪费的第一道闸门。

我们定义了三类必须拦截的输入：

• 纯闲聊类（Chit-Chat）：使用一个 500 行的规则引擎判断。例如：

  • 包含问候词（“你好”“hi”）且无动词 → 拦截，返回预设欢迎语；
  • 包含感叹词（“哇”“太棒了”）且无业务关键词 → 拦截，返回情绪回应；
  • 问句无宾语（“怎么样？”“好吗？”）→ 拦截，引导用户补充信息。

• 知识问答类（QA）：当 query 明确匹配 FAQ 库（我们用 Elasticsearch 构建，支持同义词扩展），且答案置信度 >0.95，则跳过 Agent，直接返回结构化答案。FAQ 库每天凌晨自动同步知识库更新。

• 低价值操作类（Low-Value Action）：例如“把字体调大一点”“换个主题色”。这类请求不涉及业务数据，由前端直接处理，不走后端 Agent。我们在 API 网关层就做了路由，/api/ui/*请求直通前端，/api/agent/*才进 Agent 流程。

这个决策点的实现，让我们单日 Agent 调用量下降 31%，而用户满意度（CSAT）反而上升 2.3 个百分点——因为用户不再需要等待 2 秒去听一个“你好呀”的回复。

3.3 决策点三：意图识别分流——LLM 不是万能的，但它是最后一道防线

第三决策点，是意图识别的分流开关。它决定：这个 query，该交给哪一层意图识别器来处理？

分流逻辑基于两个实时指标：

• query 长度（token_count）：短 query（<15 tokens）走 L1/L2，长 query（>50 tokens）必须走 L4/L5；
• 历史意图稳定性（intent_stability_score）：计算该用户近 10 次请求的意图分布熵值。熵值低（<0.3）说明用户意图稳定，优先用 L2/L3；熵值高（>0.7）说明用户需求多变，直接上 L4/L5。

分流伪代码如下：

def route_intent_recognition(query, user_profile): token_len = count_tokens(query) entropy = user_profile['intent_entropy'] if token_len < 15: return use_regex_or_svm(query) # L1/L2 elif token_len < 50 and entropy < 0.3: return use_tinybert(query) # L3 else: return use_llm_zero_shot(query) # L4

这个设计的价值在于：用最小成本解决大部分问题，把 LLM 的昂贵算力留给真正需要它的长尾场景。我们监控显示，L1/L2 处理了 73% 的请求，平均延迟 8ms；L4/L5 处理 27%，平均延迟 620ms。整体 P95 延迟稳定在 120ms 以内。

3.4 决策点四：工具路由准入——七道门，一道都不能少

第四决策点，即工具路由的七重检查（详见 2.4 节），是整个 Agent 最关键的安全部。这里重点讲一个实战技巧：如何让七重检查不拖慢性能？

我们的方案是“预计算 + 异步校验”：

• 预计算：对每个用户，每日凌晨批量计算其权限、配额、地域合规策略，结果存入 Redis Hash，key 为user_policy:{uid}。检查时直接HGETALL，O(1) 复杂度。
• 异步校验：健康检查（Health Gate）和数据范围检查（Scope Gate）不阻塞主流程。主流程拿到工具列表后，立即发起异步任务校验，同时返回{"status": "validating", "tool_id": "refund_v2"}。前端显示“正在验证支付通道...”，300ms 内异步任务完成，通过则执行，失败则推送错误。

这个设计让工具路由的平均耗时从 1.2s 降至 45ms，P99 仍控制在 110ms。更重要的是，它把“失败”变成了可预期的用户体验，而非不可控的超时。

4. 循环机制深度解析：Agent 不是单次调用，而是一场精密的状态舞蹈

4.1 为什么“循环”不是可选项，而是必选项？

很多人认为 Agent 就是“用户问→LLM 思考→调工具→返回结果”一次完成。这是对 Agent 最大的误解。真实世界的问题，极少能单步解决。用户说“帮我分析上季度销售数据”，背后隐藏着至少五个子问题：

1. 数据在哪里？（查元数据）
2. 上季度是哪段时间？（时间解析）
3. 销售数据包含哪些字段？（Schema 查询）
4. 用户需要什么维度的分析？（钻取、聚合、对比）
5. 结果以什么格式呈现？（Excel/PDF/图表）

这五个子问题，构成一个天然的决策-执行-反馈循环。循环不是为了炫技，而是为了把一个模糊的大目标，分解为一系列可验证、可中断、可重试的小目标。

我们的循环机制设计遵循三个铁律：

• 每次循环必须产生一个可验证的中间产物（Intermediate Artifact）：如 SQL 查询语句、API 请求参数、图表配置 JSON。产物必须落库（我们用 PostgreSQL 的artifacts表），带唯一cycle_id。
• 每次循环必须有明确的退出条件（Exit Condition）：要么成功产出最终结果，要么触发预设的失败策略（如重试 3 次、降级为人工、返回错误）。
• 循环状态必须全局可见（Global Visibility）：所有中间产物、决策日志、耗时统计，实时推送到监控大盘。运维人员能随时看到“当前第几轮循环”“卡在哪个节点”“已耗时多久”。

4.2 循环的四种模式：按需选择，拒绝一刀切

我们不采用单一循环模型，而是根据业务场景预设四种模式，由意图识别器自动选择：

选择逻辑写在CyclePlanner类中：

def plan_cycle(intent, context): if intent in ["weather", "time", "currency"]: return DirectCycle() elif intent == "book_meeting": return ConditionalCycle(max_rounds=2) elif intent == "generate_ppt": return IterativeCycle(max_rounds=5) elif intent in ["transfer_large_sum", "refund_high_value"]: return HumanInLoopCycle()

这种设计让循环机制不再是黑盒，而是可预测、可配置、可审计的工程组件。

4.3 状态快照（State Snapshotting）：循环不崩溃的秘密

循环机制最大的风险是状态丢失。网络抖动、服务重启、超时中断，都可能导致 Agent 卡在中间状态，既不成功也不失败。我们的解决方案是：每次循环开始前，强制保存完整状态快照；每次循环结束后，原子性更新状态。

快照内容包括：

• 输入快照（Input Snapshot）：原始 query、解析后的结构化参数、用户上下文图谱摘要；
• 决策快照（Decision Snapshot）：本循环选择的工具、调用参数、LLM 的思考过程（system prompt + user message + assistant response）；
• 执行快照（Execution Snapshot）：工具调用的 request/response、耗时、HTTP 状态码、错误堆栈；
• 输出快照（Output Snapshot）：本循环产生的中间产物（如 SQL 语句、API 返回 JSON）。

所有快照存入 PostgreSQL 的state_snapshots表，cycle_id为主键。关键设计：

• 快照写入与循环执行在同一数据库事务中：保证“快照存在”即“循环已启动”，避免状态不一致；
• 快照压缩：对大文本（如 LLM response）用 LZ4 压缩，节省 62% 存储空间；
• 快照索引：在user_id,intent,created_at上建复合索引，支持按用户查所有循环、按意图查失败案例。

这个机制让我们实现了 99.99% 的循环可靠性。过去一年，因状态丢失导致的用户投诉为 0。更重要的是，它让问题排查变得极其简单：运维只需输入user_id和时间，就能看到整个循环的每一步快照，像看录像一样复现问题。

5. 工程落地避坑指南：那些文档里绝不会写的血泪教训

5.1 坑一：LLM 的“自信幻觉”——它总在不懂时瞎编，还编得特别像

这是 Agent 开发者踩得最多、最深的坑。LLM 不会说“我不知道”，它会说“根据我的知识，XXX”。我们曾上线一个“期货交易建议”Agent（仅供内部学习，不对外），LLM 在用户问“螺纹钢期货下周走势”时，一本正经地编造了一个“中国钢铁协会最新政策解读”，连文件号都编得有模有样。用户截图发群里，差点引发舆情。

真实解决方案：

• 强制引用溯源（Citation Enforcement）：所有 LLM 输出必须标注信息来源。我们修改了提示词，在 system prompt 末尾加：

  IMPORTANT: If you reference any data, policy, or fact, you MUST cite it using [SourceX] format, where X is the index of the source in the provided context. If no source is provided, DO NOT invent facts. Say "I cannot answer based on available information."

• 事实核查层（Fact-Checking Layer）：在 LLM 输出后，增加一个轻量级核查服务。它用关键词抽取 LLM 回复中的实体（如“中国钢铁协会”“2024年第5号文”），然后调用权威知识库 API 校验。不匹配？直接拦截，返回{"error": "unverifiable_claim", "suggestion": "请咨询专业机构"}。
• 置信度熔断（Confidence Circuit Breaker）：对 LLM 的输出，我们用另一个小模型（DistilRoBERTa）评估其“事实一致性得分”。得分 <0.6？拒绝输出，触发降级。

教训：永远假设 LLM 会撒谎。你的责任不是让它更聪明，而是建一道墙，让它撒的谎出不了你的系统。

5.2 坑二：工具调用的“雪崩效应”——一个慢工具，拖垮整个 Agent

我们曾遇到一个经典故障：支付网关偶尔超时（>5s），导致 Agent 的refund_tool调用 hang 住。由于默认超时设为 10s，且未做熔断，大量请求堆积，最终拖垮整个服务，P99 延迟飙升至 15s。

真实解决方案：

• 分级超时（Tiered Timeout）：每个工具配置三级超时：
  • fast_timeout: 200ms（用于健康检查、缓存查询）
  • normal_timeout: 2s（用于大多数 API 调用）
  • slow_timeout: 5s（仅用于大数据导出等明确慢操作） 调用时，先用fast_timeoutping，失败则降级；成功则用normal_timeout执行。
• 熔断器（Circuit Breaker）：集成 Resilience4j，当refund_tool连续 5 次失败，自动熔断 30 秒，期间所有请求直接返回{"error": "service_unavailable"}。
• 降级策略（Fallback Strategy）：熔断时，不是简单报错，而是提供替代方案。例如refund_tool熔断，自动切换到refund_email_template工具，生成一封标准退款申请邮件，用户点击即可发送。

这个组合拳让我们把工具故障的 MTTR（平均修复时间）从 45 分钟降至 90 秒，用户无感。

5.3 坑三：上下文膨胀——越聊越慢，越聊越错

随着会话延长，上下文 token 数指数级增长。我们一个客服 Agent，用户聊到第 12 轮时，上下文已达 4200 tokens，LLM 响应时间翻倍，且开始遗忘早期关键信息（如用户手机号）。

真实解决方案：

• 动态上下文裁剪（Dynamic Context Pruning）：不简单删旧消息，而是基于图谱权重裁剪。算法：
  1. 计算每条历史消息对当前 query 的相关性分数（用 sentence-BERT 计算余弦相似度）；
  2. 按分数排序，保留 top-K 条（K 动态计算：max(3, min(10, 4000 // avg_token_per_msg))）；
  3. 对保留的消息，只保留与当前意图相关的片段（如用户说“我的订单号是12345”，当前意图是“查订单”，则只保留“12345”）。
• 关键信息外提（Key Info Extraction）：在每轮对话结束时，用一个专用小模型（微调的 TinyBERT）提取 3 个最关键实体，存入图谱。后续只需注入这 3 个实体，而非整段历史。
• 会话分片（Session Sharding）：当会话超过 15 轮，自动创建新会话 ID，旧会话归档，新会话从干净状态开始。用户无感知，后台自动关联。

实施后，平均上下文长度从 3200 tokens 降至 850 tokens，P95 延迟下降 63%，关键信息召回率保持 99.5%。

5.4 坑四：安全边界模糊——Agent 不是玩具，是生产系统

Agent 安全不是“防黑客”，而是“防误用、防越权、防泄露”。我们曾发生过一起事故：用户输入“把我的所有订单导出”，Agent 未做数据范围检查，直接调用export_all_orders工具，导出了该用户 5 年来的全部订单，包含敏感字段（身份证号、银行卡尾号），PDF 文件被用户下载后传播。

真实解决方案：

• 数据沙箱（Data Sandbox）：所有工具访问数据库，必须通过一个代理层。该层强制：
  • SELECT * FROM orders→ 重写为SELECT order_id, product_name, amount, status FROM orders WHERE user_id = ?；
  • 自动脱敏：id_card字段返回***1234，bank_card返回****5678；
  • 行数限制：LIMIT 1000，超限需人工审批。
• 工具白名单（Tool Whitelist）：每个用户角色只能调用预设工具集。普通用户看不到export_all_orders，VIP 用户看到，但调用时仍受沙箱限制。
• 操作审计（Operation Audit）：所有工具调用，无论成功失败，都记录完整审计日志：user_id,tool_name,input_params（脱敏）,output_size,duration,ip_address。日志实时接入 SIEM 系统，设置规则“单用户 1 小时内导出数据 >10MB”即告警。

这套机制让我们通过了金融行业最严苛的等保三级认证，至今零数据泄露事件。

6. 性能与并发：当“AI Agent 怎么扛并发”成为生死线

6.1 并发的本质：不是 QPS，而是状态隔离粒度

网上热议“AI Agent 怎么扛并发”，本质是混淆了概念。HTTP 接口的并发（QPS）和 Agent 的并发，是两回事。一个 HTTP 请求可以承载多个 Agent 会话，一个 Agent 会话可以包含多个并行工具调用。真正的并发瓶颈，在于状态管理的粒度。

我们采用三级状态隔离：

• 会话级隔离（Session-Level Isolation）：每个用户会话拥有独立的SessionState对象，内存中驻留，Redis 中持久化。这是最细粒度，保证用户间绝对隔离。
• 意图级隔离（Intent-Level Isolation）：同一会话内，不同意图（如“查订单”和“退钱”）使用不同的IntentContext，避免状态污染。例如查订单的order_id不会污染退钱的refund_reason。
• 工具级隔离（Tool-Level Isolation）：每个工具调用在独立线程/协程中执行，共享会话状态，但有自己的临时上下文。我们用 asyncio.Semaphore 控制并发数，refund_tool最多 5 个并发，weather_api最多 50 个。

这种设计让我们单实例支撑 1200 QPS，P99 延迟 180ms。关键指标：

• 会话状态内存占用：<1.2MB/会话；
• Redis 状态读写耗时：<15ms（P99）；
• 工具调用并发控制精度：±0.3%（实测）。

6.2 异步编排：让 LLM 等待，让工具并发

Agent 的最大性能杀手，是“串行等待”。用户说“查天气+查股票+查快递”，传统做法是让 LLM 依次调用三个工具，总耗时 = LLM1 + 天气 + LLM2 + 股票 + LLM3 + 快递。

我们的方案是：LLM 只负责“计划”，工具调用完全异步并发。

流程：

1. LLM 接收 query，输出 JSON 计划：`{"tools": [{"name": "weather", "params