企业官网建设流程全解析

1. 为什么要把大语言模型放进网络防御闭环里

第一次在值班表旁边摆一台大模型的时候，很多人心里其实是发虚的。传统 SIEM 加规则引擎跑得好好的，为什么要让一个“会说话”的模型来参与判断告警？这个疑问非常合理，因为大型语言模型作为自主网络防御者这件事，真正有价值的部分不是让它去“猜攻击”，而是让它承担一件人做起来最累、机器做起来最关键的工作：把散落在十几个系统里的证据碎片拼成一个能被人快速采信的判断，并且把标准化的处置动作跑完。

我参与过一个中型的防守场景，日志、EDR 遥测、资产库、漏洞扫描结果、历史工单分别落在五个系统里，值班同事拿到一条高危告警后，平均要切六到八个页面，翻四五份文档，才能确认“这台机器到底是不是核心资产、这个进程是不是业务在用的、这个外联是不是白名单里的出口”。单条告警研判 12 到 20 分钟，夜间只有两个人值班，告警峰值一来，积压是必然的。真正的问题从来不是检测能力不够，而是研判与处置这一段的人力带宽太窄。大型语言模型恰好在这个位置上能顶上来：它擅长读非结构化文本、擅长按既定流程调用工具、擅长把多源信息归纳成一段结论，还擅长按照固定的输出格式交代自己的依据。

这篇文章想讲清楚的就是这套东西怎么落。适合谁看：正在做安全运营中心建设的工程师、想把模型能力接进告警流水线的平台开发、以及被“每天几百条告警看到麻木”困扰的值班负责人。全文会从架构设计、证据构造、工具契约、误报控制一路讲到实操代码和踩坑记录，尽量给到能直接照着搭的细节。有些环节是我在实际环境里试出来的，有些则是行业里比较通行的做法，我会标明哪些是通用实践、哪些是我的个人取舍。

1.1 传统检测流水线到底卡在哪个环节

规则引擎并不弱，弱的是“规则的输出”和“人的决策”之间那段空白。一条规则命中，输出的是“某主机在某时刻出现了某行为”，这只是一个事实陈述，离“该不该处置”还隔着好几层判断：这台主机承载什么业务、这个行为在当前变更窗口里是否预期、这个外联目标在历史上有无出现过、同一批次的其它主机有没有类似现象、上次类似告警是怎么被关闭的。这些判断大量依赖上下文，而上下文恰好是规则引擎最不擅长的部分。

更麻烦的是上下文本身是异构的。资产库是结构化表格，历史工单是半结构化文本，值班记录是纯自然语言，威胁情报是大量嵌套的 JSON。传统做法是给每类数据写解析器，再写一堆 if-else 把结论拼起来，维护成本极高，而且每加一个新数据源就要改一次代码。我见过一个团队为了让“外联是否可疑”这一条判断更准，硬是在解析层堆了三千多行代码，最后没人敢动。

大型语言模型在这个位置的优势，是把“多源异构数据的语义归并”从代码问题变成了提示与工具调用问题。你不需要为每个新数据源写解析逻辑，只需要给它一个查询工具的接口和一份说明，它就能在推理链里自己决定要查什么、查到之后怎么用。这是我认为它值得进闭环的第一个理由。

1.2 大模型在防御侧的三个真实能力位

把能力吹得太大没有意义，我在实践中只把它放在三个位置上，多一个都不放。

注意第三个能力位常被低估。实际上值守团队最缺的往往不是“判断”，而是“判断完之后没人写记录”。一份像样的复盘要包含时间线、证据链、决策依据、后续动作，人工写要半小时，模型写初稿只要几十秒，人只需要校对。这一块的价值回收特别快，也是很多团队愿意先从这里试水的原因。

至于“让模型自己去发现新型攻击”，我的态度很保守。不是做不到一部分，而是验证成本太高：模型说“这里有异常”，你得先证明它不是在幻觉，这个证明成本可能比人工排查还高。所以在自主性上必须分级，这是下一节要说的。

1.3 自主性的分级：从助手到值班员

“自主”这个词很容易被误解成“全自动”。我给这套系统设计的分级是这样的，实际部署时也是逐级放开：

• L0 只读助手：模型只能查，不能改。输出研判结论给人工确认。这一级几乎无风险，适合起步。
• L1 建议处置：模型给出处置建议和具体命令，人工一键执行。人在环上，但省掉了“想方案”的时间。
• L2 限定自动：对白名单内的动作类型（如临时封禁某类外联、给主机打隔离标签）在置信度超过阈值时自动执行，其余仍需人工。
• L3 闭环自治：全流程自动，人工只做事后抽检。这一级我只在低危场景（如清理过期临时账号、关闭明显误报工单）见过稳定运行。

绝大多数团队的现实目标是L2，不是 L3。原因很实在：一次误隔离造成的业务损失，可能抹掉大半年的效率收益。所以我在设计里把“自动执行的边界”做得极窄，只放那些可回滚、影响面可控、且失败代价低的动作。这个取舍贯穿了后面所有的架构决策。

2. 系统整体架构：把“自主”拆成可验证的模块

一套能上生产的东西，最忌讳的就是“一个大模型包打天下”。我在架构上做了很硬的切分，核心思路是：模型的输出永远只是“意图”，真正的动作由确定性的执行层完成，中间隔一层可审计的契约。这样即使模型抽风，损失也被限制在契约允许的范围内。

2.1 四层结构：感知、推理、决策、执行

先说分层。我用的是四层，边界很清楚：

第一层感知层，负责把各类遥测数据归一化成事件。它不关心业务语义，只做格式统一、字段映射、时间对齐。这一层用传统的流处理框架就够了，不需要模型参与。

第二层推理层，也就是模型所在的位置。它拿到的是一个“证据包”，里面已经预填了一批基础信息（告警原文、主机的资产标签、相关进程树摘要），然后它通过工具调用去补充缺失的部分。

第三层决策层，负责把模型的自然语言结论转成结构化的决策对象，并做阈值判定、白名单校验、幂等检查。这一层是纯代码，不含任何模型调用。

第四层执行层，真正去调 SOAR、防火墙管理接口、工单系统。它对上游只暴露固定参数的动作接口，且每个动作都必须带可回滚标记。

这个分层最直接的好处是可观测。当出错时，你能立刻定位是证据不全（感知层）、推理跑偏（推理层）、阈值不合理（决策层）还是动作执行异常（执行层）。如果全揉在一起，出了问题只能靠猜。

提示：不要在推理层里直接写数据库或调防火墙接口。模型能触达的“工具”必须是你主动暴露的、参数受控的、有日志的窄接口。这条如果守不住，后面所有的安全设计都是空谈。

2.2 工具调用层的设计原则

工具层是整套系统里我最愿意花时间打磨的部分。原则就四条：

第一个原则，工具要少而稳。很多团队一上来就给模型挂二三十个工具，结果模型在工具选择上频繁出错，调用次数暴涨，成本和时间都失控。我在实践里控制在 8 到 12 个，每个工具对应一类查询，用清晰的描述区分开。真正高频的其实就那几个：查资产、查进程详情、查网络连接历史、查历史相似告警、查情报信誉、执行处置、写工单。

第二个原则，工具返回要预压缩。直接把几十 KB 的原始日志塞回模型，既贵又容易淹没有效信息。我的做法是工具内部先做聚合，比如“查网络连接历史”返回的不是全部连接，而是最近 24 小时的连接数、去重后的目标地址 TOP N、以及首次/末次出现时间。这个聚合逻辑写在工具里，不写在提示里，因为代码比提示可靠。

第三个原则，工具有硬超时和失败语义。某个数据源挂了，工具必须快速返回“查询失败”而不是卡死。模型拿到失败结果后要能降级处理，比如“资产信息获取失败，按未知资产处理，建议人工确认”。我在提示里明确写了这条降级规则，实测下来能避免大量因单点故障导致的全流程卡死。

第四个原则，所有工具调用必须留痕。每次调用的入参、出参摘要、耗时都进审计表。这既是合规要求，也是调优的依据——你只有知道模型爱查什么、哪些查询常年返回空，才能把工具和提示改好。

2.3 记忆与上下文管理

告警研判是典型的多轮任务，模型需要记住“我已经查过资产了，它是核心系统”“我已经确认这个外联在历史白名单里”。如果不做管理，上下文会迅速膨胀，成本和延迟都不可接受，而且早期信息容易被稀释。

我的做法是三段式：固定头部 + 滚动摘要 + 关键证据常驻。

固定头部是系统提示和流程规范，永远在最前面，保证行为一致性。滚动摘要是每完成一个阶段就压缩一次，比如“已完成资产与进程核查，主机为核心业务节点，进程为已知业务组件，未发现异常”。关键证据常驻指那些带证据 ID 的原始片段，完整保留，因为最终结论必须能引用它们。

这里有个很实用的细节：摘要由模型自己生成，但必须保留证据 ID 列表。如果摘要丢了证据 ID，后续结论就成了无源之水，你没法验证它是不是编的。我在摘要模板里强制要求输出evidence_ids字段，缺了就让这次生成重试。这个小小的约束，把幻觉率压下来一大截。

3. 核心细节：证据构造、工具契约与误报控制

架构只是骨架，决定成败的是细节。这一节讲三件事：给模型喂什么样的证据、怎么约束它的输出、以及怎么把误报率压到能接受的水平。这三件事凑在一起，才是“能用”和“不能用”的分界线。

3.1 证据包怎么构造才不会喂偏

证据包的设计直接决定研判质量。我踩过的最大的坑是一开始把所有能拿到的字段全塞进去，结果模型被大量无关信息干扰，结论经常跑偏到一些边角细节上。后来改成“必需字段 + 按需查询”的两段式，效果立刻不一样。

必需字段只放五类，控制在很小的体积内：告警原文（规则名、触发时间、命中字段）、主机基础信息（资产等级、业务归属、责任人）、进程摘要（父进程链、命令行、签名状态）、网络摘要（目标地址、端口、连接频次）、历史命中（近 30 天同类告警次数与处置结果）。这五类的共同特点是能直接支撑“该不该处置”这个判断。

其余信息一律通过工具按需拉取。比如模型看到“进程签名为空”，可以主动调“查文件哈希信誉”；看到“目标地址是陌生 IP”，可以调“查情报信誉”。这种按需拉取比一次性全塞有两个好处：一是上下文干净，二是调用链本身就是推理过程的可解释记录。

下面这段是我实际用的证据包构造函数，精简过但保留了关键结构：

from dataclasses import dataclass, field, asdict import hashlib, json, time @dataclass class Evidence: evidence_id: str kind: str # alert / asset / process / network / history payload: dict fetched_at: float = field(default_factory=time.time) @staticmethod def build(kind: str, payload: dict) -> "Evidence": raw = json.dumps(payload, sort_keys=True, ensure_ascii=False) eid = f"EV-{hashlib.sha1(raw.encode()).hexdigest()[:10]}" return Evidence(evidence_id=eid, kind=kind, payload=payload) def build_alert_packet(alert, asset_client, edr_client, history_client): """构造首轮证据包，只放必需字段，其余留给模型按需查询""" evidences = [] evidences.append(Evidence.build("alert", { "rule_name": alert.rule_name, "severity": alert.severity, "fired_at": alert.fired_at, "host": alert.host, "hit_fields": alert.hit_fields, })) asset = asset_client.get(alert.host) evidences.append(Evidence.build("asset", { "asset_level": asset.level, # core / important / normal "owner_team": asset.owner_team, "os": asset.os, "exposed_to_internet": asset.exposed, })) proc = edr_client.recent_process(alert.host, window_min=10) evidences.append(Evidence.build("process", { "chain": proc.parent_chain, "cmdline": proc.cmdline, "signer": proc.signer or "", "hash": proc.sha256, })) hist = history_client.similar(alert.rule_name, alert.host, days=30) evidences.append(Evidence.build("history", { "hit_count": hist.count, "last_verdicts": hist.verdicts[:5], })) return [asdict(e) for e in evidences]

这段代码的关键不在语法，而在字段选择。asset_level用了三级枚举而不是原始标签，last_verdicts只保留最近 5 条，chain只保留父链不保留全部子进程。每个字段都问过自己一句：模型知道这个，会不会改变结论？答不上来的就砍。

3.2 工具契约与结构化输出

模型输出必须是结构化的，这一点没有商量余地。自然语言结论没法做阈值判定，也没法做幂等检查。我用的是 JSON Schema 约束加解析后校验的双保险。

输出对象的设计我是这样定字段的：

{ "verdict": "malicious | suspicious | benign | insufficient", "confidence": 0.0, "summary": "一句话结论，不超过 80 字", "evidence_ids": ["EV-xxxx", "EV-yyyy"], "reasoning": ["要点1", "要点2"], "recommended_action": { "type": "isolate_host | block_egress | create_ticket | notify_owner | none", "target": "host-or-ip", "rollback_plan": "回滚方式说明" }, "missing_info": ["还缺什么信息才能提高置信度"] }

verdict用四值而不是二值，是我特意加的。实际运营中“证据不足”是极其常见的状态，如果只有“恶意/良性”两个选项，模型会被逼着在一个它并不确定的情况下硬给结论，这正是误报的主要来源之一。给它一个“insufficient”的出口，反而让它在有把握的时候更敢下判断。

evidence_ids是防幻觉的核心。我在校验层做了一件事：核对每个 ID 是否真的存在于本轮证据池，不存在就把这条证据从结论里剔除，并记一次“引用违规”。如果一条结论的所有证据 ID 都不合法，直接判定本次输出无效，退回重跑。

missing_info这个字段看起来像装饰，实际用处很大。运营一段时间后，你把这些字段聚合统计，就知道“模型最常缺什么信息”，这直接告诉你下一步该接哪个数据源。我们统计过一段时间，发现“缺进程签名信息”占比最高，补了一个签名查询工具之后，整体置信度中位数提升了很明显。这种从数据反推建设方向的循环，比拍脑袋接系统靠谱得多。

3.3 置信度分档与人工兜底的阈值设定

阈值这个东西没有通用解，但设定方法可以通用。我的方法是从历史数据反推，而不是拍脑袋定 0.8。

具体做法：拿过去半年的已处置告警做一批标注样本，让模型跑一遍，得到每条告警的置信度与真实标签。然后画一张表，看不同阈值下自动执行的精确率和覆盖率：

这张表是虚构的示例数据，但形状很典型：阈值每降 0.05，覆盖率涨得很快，精确率掉得也快。选哪个点取决于你的一次误判代价和人力成本的比值。如果误隔离一台核心主机的代价是数十人时，那 0.90 往上更安全；如果只是关一个误报工单，代价几分钟，0.80 也敢放。

我实际采用的是分动作分阈值：可回滚的轻动作用低阈值（0.80），影响面大的重动作用高阈值（0.95 以上），且重动作必须有第二模型交叉验证或人工确认。这种差异化阈值比统一阈值实用得多，因为它把风险和收益匹配上了。

还有一个容易忽略的点：阈值要随资产等级浮动。同样是“疑似外联异常”，核心系统上的判定阈值要比普通办公机更高。我在决策层里加了一条硬规则：资产等级为 core 的主机，无论模型置信度多少，处置动作一律走人工确认。这条规则救过我们至少一次。

3.4 误报抑制的几个实操细节

误报是这套系统最容易翻车的地方，也是决定它能不能活过试用期的关键。我总结了几个实测有效的做法。

第一，让模型先找“合理解释”再下结论。提示里我强制要求先写一段“寻找良性解释”，比如“该进程是否为已知业务组件”“该外联是否在历史白名单中出现过”“该行为是否处于计划变更窗口内”。只有良性解释全部被排除，才允许给出恶意结论。这个顺序调整让误报率有明显下降，因为大量误报本质上是“模型没往正常方向想”。

第二，把“历史关闭原因”作为强特征喂进去。很多告警在同一条规则上反复触发，历史上被关闭的理由往往是“业务方确认是正常行为”。这类信息对模型极有价值。我在证据包里专门放了last_verdicts，并且在提示里明确说：如果最近 5 条同类告警均被人工判定为误报，且本次无新增异常特征，置信度应显著下调。

第三，对时间窗口做敏感性检查。单点时刻的异常，很多时候是采集抖动或短暂峰值。我在工具里提供“同主机近 1 小时同规则触发次数”，如果只有 1 次，模型需要更多佐证；如果短时间内密集触发，才是真正的异常信号。这个维度加进去之后，那些一闪而过的采集噪声被过滤掉不少。

第四，建立误报回流机制。每次人工推翻模型结论，都要把这个 case 的结构化摘要（证据包 + 模型结论 + 人工结论 + 差异点）存起来，定期做提示迭代和少样本示例更新。这个闭环不建，系统会一直停在初始水平。我们大概每两周做一次回流分析，把高频误判模式写成提示里的约束条款，效果是滚雪球式的。

4. 实操落地：从一条告警到一次处置

前面讲的是设计，这一节讲怎么真的跑起来。我会给出一个可执行的最小链路，包含环境准备、核心代码、权限边界和评估方法。代码是简化版，但结构完整，你可以直接照着改。

4.1 环境与依赖准备

依赖不多，重点是几件事：模型服务的调用封装、工具注册机制、结构化输出校验、审计落库。我用 Python 写的，原因很简单，生态全、迭代快，安全团队普遍能维护。

python -m venv venv && source venv/bin/activate pip install fastapi uvicorn pydantic jsonschema redis psycopg2-binary tenacity

几个依赖的作用：pydantic和jsonschema管输出校验，redis管幂等键和短期缓存，psycopg2-binary落审计，tenacity做重试。工具调用层建议单独起一个内部服务，不要和执行层混在一起，方便单独限流和审计。

配置上我强调三个环境变量必须分开管理：模型服务地址、动作执行接口凭证、审计库连接串。前两个绝不能放在同一份配置里被同一权限读到，否则一次泄露就能同时拿到“思考能力”和“动手能力”。

# config.yaml 结构示意 model: endpoint: "https://内部网关/兼容接口/v1" name: "内部部署的推理模型" max_tokens: 2048 temperature: 0.1 # 研判任务必须低温度，保证稳定 timeout_s: 45 tools: max_calls_per_alert: 10 # 硬上限，防止无限调用 per_call_timeout_s: 8 decision: auto_execute_threshold: 0.90 hard_confirm_asset_levels: ["core"] allowed_auto_actions: ["block_egress", "create_ticket"] audit: store_tool_calls: true store_full_prompt: false # 只存摘要，控制体积

temperature设成 0.1 是刻意的。研判不是创作，要的是同一个输入尽量得到同一个输出，可复现性比多样性重要得多。max_calls_per_alert这个硬上限也很关键，我在测试阶段见过模型陷入“查不到就再查一次”的循环，加了上限之后这类问题彻底消失。

4.2 告警研判链路的核心实现

主流程是：拿告警 → 构造证据包 → 进入推理循环（模型决定调哪个工具）→ 拿到结构化输出 → 校验 → 决策层判定 → 执行或转人工。我把中间最关键的两段贴出来。

第一段是推理循环，重点是工具调用的收口和循环上限：

import json from tenacity import retry, stop_after_attempt, wait_fixed, retry_if_exception_type MAX_ROUNDS = 8 def investigate(alert, llm, tools, evidence_pool): messages = [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": render_alert_packet(evidence_pool)}, ] tool_calls_made = 0 for _ in range(MAX_ROUNDS): resp = llm.chat(messages=messages, tools=tools.specs(), temperature=0.1, max_tokens=2048) msg = resp.choices[0].message if not msg.tool_calls: return parse_and_validate(msg.content, evidence_pool) messages.append(msg) for call in msg.tool_calls: if tool_calls_made >= 10: messages.append({ "role": "tool", "tool_call_id": call.id, "content": json.dumps({"error": "tool_call_budget_exhausted"}) }) continue result = tools.invoke(call.function.name, json.loads(call.function.arguments)) tool_calls_made += 1 evidence_pool.absorb(call.function.name, result) messages.append({ "role": "tool", "tool_call_id": call.id, "content": json.dumps(result, ensure_ascii=False)[:4000] }) # 轮次耗尽仍无结论，降级为证据不足，交人工 return {"verdict": "insufficient", "confidence": 0.0, "summary": "推理轮次耗尽，证据不足", "evidence_ids": [], "recommended_action": {"type": "create_ticket", "target": alert.host, "rollback_plan": "无需回滚"}}

这里有两个刻意设计：工具结果截断到 4000 字符，防止单次返回把上下文撑爆；轮次耗尽时不报错，而是降级成“证据不足转人工”。生产环境里最怕的就是异常路径直接抛错导致告警丢单，降级比报错安全得多。

第二段是校验与决策，这是防幻觉的最后一道闸：

def parse_and_validate(raw, evidence_pool): try: obj = json.loads(raw) except json.JSONDecodeError: return invalid("输出非合法 JSON") if obj.get("verdict") not in {"malicious","suspicious","benign","insufficient"}: return invalid("非法 verdict") valid_ids = set(evidence_pool.ids()) cited = obj.get("evidence_ids", []) illegal = [e for e in cited if e not in valid_ids] obj["evidence_ids"] = [e for e in cited if e in valid_ids] if illegal: audit.record("citation_violation", {"illegal": illegal, "raw": obj}) # 恶意/可疑结论必须至少引用一条证据，否则降级 if obj["verdict"] in {"malicious","suspicious"} and not obj["evidence_ids"]: obj["verdict"] = "insufficient" obj["confidence"] = 0.0 return obj def decide(obj, alert, asset): act = obj.get("recommended_action", {}) atype = act.get("type", "none") if obj["verdict"] == "benign": return Decision("close_ticket", reason=obj["summary"]) if asset.level == "core": return Decision("request_human", reason="核心资产强制人工确认") if atype in {"isolate_host"}: return Decision("request_human", reason="高危动作需人工确认") if (atype in {"block_egress","create_ticket"} and obj["confidence"] >= 0.90 and not is_already_done(alert.host, atype)): return Decision("auto_execute", action=act, reason=obj["summary"]) return Decision("request_human", reason=obj["summary"])

is_already_done那个幂等检查是血泪教训。早期没做幂等，同一条告警因为重试机制被处理了两次，第二次的“封禁”动作覆盖了人工刚刚解除的封禁，把业务方坑了一把。加上幂等键（主机 + 动作类型 + 时间桶）之后，这类问题再没出现过。

4.3 处置动作的权限边界与回滚设计

自动处置最需要想清楚的不是“怎么执行”，而是“执行完怎么退回来”。我给每个动作都定了三件事：生效范围、生效时长、回滚方式。

临时封禁类动作我全部设了自动过期，默认 30 分钟，最长不超过 2 小时，到期自动解除。理由很实在：如果封错了，业务方最多难受半小时，而且不需要有人记得去解封。这个设计把误封的代价从“可能持续数天”压到了“半小时”。

隔离类动作我从不让模型直接触发，一律走人工确认。不是因为技术上做不到，而是因为隔离的副作用太不可控——你永远不知道那台机器上有没有别人在跑的自动化任务。有一次测试环境误隔离了一台构建机，导致整条流水线卡了一个下午，虽然没造成实际损失，但这个教训足够让人警醒。

回滚方案必须和执行方案一起生成，写进工单。我在提示里明确要求rollback_plan字段不能为空，且必须是可操作的描述，不能写“联系管理员处理”这种废话。校验层会检查这个字段长度和关键词，太敷衍的直接打回。

审计这块我建议做到能重建整个决策过程。每条告警存：证据包全量、工具调用序列、模型原始输出、校验后的对象、最终决策、执行结果。存储成本不低，但出事时的价值无可替代。曾经有一次人工质疑某个自动关闭的工单，靠审计记录十分钟就还原了完整推理链，证明模型判断是对的，省去了扯皮。

4.4 怎么衡量这套系统到底有没有用

不上量化指标，这套东西就永远说不清价值。我用的指标体系分两层。

效率层看三个数：平均研判耗时（从告警产生到决策落地的时长）、人工介入率（需要人看一眼的比例）、工单积压峰值。这三个数是最容易向管理层交代的。

质量层看四个数：自动执行精确率（自动执行中被正确执行的比例）、误隔离率、漏判率（用事后回溯样本估）、证据引用合法率。质量层的指标不好看，效率层的数字再漂亮也没意义。

评估方法我建议做离线回放 + 小流量在线两段。离线回放拿历史告警批量跑，成本低、无风险，能快速迭代提示和工具；在线只放一小部分流量（比如 5%），观察一段时间再逐步放大。这个节奏下，即使模型有系统性问题，影响面也可控。

def evaluate_offline(cases, investigator): stats = {"total": 0, "auto": 0, "auto_correct": 0, "insufficient": 0, "citation_violation": 0} for c in cases: obj = investigator.run(c.alert) stats["total"] += 1 if obj["verdict"] == "insufficient": stats["insufficient"] += 1 if obj["decision"] == "auto_execute": stats["auto"] += 1 if c.ground_truth == obj["verdict"]: stats["auto_correct"] += 1 if obj.get("citation_violation"): stats["citation_violation"] += 1 stats["auto_precision"] = (stats["auto_correct"] / stats["auto"] if stats["auto"] else None) return stats

5. 常见问题与排查实录

跑起来之后遇到的坑，比设计阶段预想的多得多。这一节把高频问题和我的处理方式整理出来，都是可以直接对照排查的。

5.1 典型故障速查表

这张表我贴在值班位旁边的墙上，新人上手很快。里面最值得展开的是第一条和第五条。

反复调同一个工具这个问题在初期特别常见，根因几乎都是工具返回了模型看不懂的结果。比如工具返回一个嵌套三层的 JSON，模型在提示里被要求“判断是否有异常”，但它找不到明确的布尔字段，就会再调一次试图获取更清晰的信息。解法不是改提示，而是改工具：每个工具返回时必须带一个明确的status字段（ok/empty/error）和一句人话摘要。这个改动做完，重复调用率下降得非常明显。

大量证据不足这个问题要区分看待。如果集中在某几类告警上，说明这类告警的判断依赖你还没接的数据源，按missing_info聚合结果补就行。如果普遍性偏高，那可能是提示过于保守，或者阈值设置有误——模型被“证据不足转人工”这条规则吓住了，宁可不下判断。这时候需要看它是不是在证据其实充分的情况下仍然保守，如果是，就要在提示里加强“证据充分时应果断给出结论”的引导。

5.2 几个只有踩过才知道的细节

第一，别用对话历史当记忆。我一开始偷懒，把整个多轮对话原样保留，结果上下文迅速膨胀到几万 token，成本和延迟都不可接受，而且模型开始“忘事”——早期查到的关键信息被后面的噪声淹没。改成滚动摘要加证据 ID 常驻之后，情况立刻改善。教训是：上下文要主动管理，不能放任增长。

第二，提示里的示例比规则更管用。我写过很长的规则条款，什么“必须考虑资产等级”“必须排除良性解释”，效果一般。后来改成塞两三个完整的输入输出示例，模型的行为立刻稳定下来。示例的力量远大于规则描述，这是我在调优过程中最反直觉的发现。示例要选边界情况，别选那种一眼就能判断的简单例子。

第三，时间字段一定要统一时区。这个坑很隐蔽。告警时间、日志时间、资产变更时间来自不同系统，时区不一致时模型会得出“该行为发生在变更窗口内”这种完全错误的结论。我在感知层强制做了时区归一，所有时间字段统一转成带偏移量的标准格式，并且在校验层检查时间字段的合理性（比如不能出现未来时间）。

第四，模型的“自信”和“正确”不总是相关。我观察过一批样本，置信度 0.95 以上的结论里仍有错误，而那些错误往往是模型对某个字段的语义理解有偏差。所以我从来不用置信度作为唯一门槛，还会叠加规则校验：比如结论是“恶意”但证据里没有任何网络侧异常，直接降级。这种语义一致性检查比单纯看置信度靠谱得多。

第五，别指望一次调好。这套东西本质上是持续迭代的系统，不是一次交付的产品。我现在的节奏是每两周做一次回流分析，看高频误判、看引用违规、看工具调用分布，每轮改一点。跑了几个月下来，自动执行精确率从最初的九成出头慢慢爬到接近 99%，靠的就是这种小步迭代，没有什么一击必杀的办法。

第六，一定要留人工推翻的入口。不管自动化做到什么程度，值班同事必须能一键推翻模型结论，并且这个动作要能被记录和学习。如果一个系统让人没法推翻，它就一定会被绕过，那时候所有的设计都白费了。

最后分享一个我觉得很有用的做法：给模型加一个“自检”回合。在它给出最终结论之前，让它再看一遍自己的输出，检查三件事：引用的证据是否都存在、结论与证据是否一致、有没有遗漏的良性解释。这个自检回合增加的延迟很小，但对降低低级错误非常有效。我个人的体会是，把模型当成一个需要清晰指令、需要复核机制、也会犯低级错误的同事来对待，而不是当成一个魔法盒子，这套系统才可能真正在生产里活下来。