1. 项目概述：当诊断策略遇上智能体

最近在跟几个做医疗AI和金融风控的朋友聊天，大家不约而同地提到了一个痛点：大模型（LLM）智能体（Agent）的应用越来越广，但很多时候感觉是“拿着锤子找钉子”。我们设计了一套复杂的Agent工作流（Scaffolding），比如让多个Agent分工协作、反复验证，但最终效果可能还不如一个简单的提示词（Prompt）直接问。问题出在哪？核心在于，我们设计的“脚手架”（Scaffolding）和我们希望智能体执行的“诊断策略”（Diagnostic Strategy）是脱节的。

这个项目标题“Tailoring Scaffolding to Diagnostic Strategies: Theory-Informed LLM-Based Agents”精准地戳中了这个要害。它探讨的不是如何造一个更强大的锤子，而是如何根据你要钉的钉子（诊断任务）的特性，去设计和调整锤子的形状、握把乃至挥锤的姿势（智能体的协作框架）。这里的“诊断”不限于医学，而是泛指一切需要分析、推理、归因和决策的复杂任务，比如代码Bug定位、系统故障排查、金融异常交易识别、学术文献的批判性分析等。

“Theory-Informed”是另一个关键。它意味着我们的设计不是凭感觉或蛮力调参，而是需要引入认知科学、决策理论、问题求解等领域的成熟理论作为指导。例如，在医疗诊断中，有“假设演绎法”（Hypothetico-deductive reasoning）；在故障排查中，有“分而治之”（Divide and Conquer）和“故障树分析”（Fault Tree Analysis）。这些理论为我们设计智能体的思考路径和交互模式提供了蓝图。

简单来说，这个项目的核心思想是：先明确你要解决哪一类诊断问题（策略），然后根据这类问题背后的认知理论，去定制化地构建LLM智能体的协作框架（脚手架），最后用这个“量体裁衣”的智能体系统去高效、可靠地完成任务。这比用一个通用框架去套所有问题，要精准和有效得多。

2. 诊断策略的理论基石与脚手架设计原则

2.1 理解“诊断策略”：从认知模型到计算任务

诊断，本质上是一个在不确定性中寻求解释和结论的过程。不同的领域已经沉淀出不同的策略模型。我们不能只把“诊断”理解为一个黑箱函数，而是要拆解其内在的认知步骤。

以经典的“假设演绎法”为例，它通常包含几个循环迭代的阶段：

1. 信息收集与问题表征：理解初始症状或现象，将其转化为结构化的问题描述。
2. 生成初步假设：基于领域知识和模式匹配，提出一个或多个可能的根本原因。
3. 推导可检验的推论：针对每个假设，推理出“如果这个假设成立，那么我们应该观察到什么其他现象或数据”。
4. 主动探查与验证：设计查询或测试，去收集能验证或反驳这些推论的新证据。
5. 假设评估与更新：根据新证据，评估各个假设的可能性，可能排除一些，修正一些，或生成新的假设。
6. 达成诊断结论：当某个假设的证据足够强，或资源耗尽时，给出最终结论及置信度。

另一个常见策略是“差异分析”（Differential Diagnosis），它强调系统性地列出所有可能的原因，然后通过寻找关键区分特征（Discriminating Features）来逐一排除。这在医学和复杂系统故障定位中非常常见。

这些策略就是我们的“理论”。在设计脚手架时，我们必须思考：我们的智能体系统如何映射这些认知步骤？每个步骤由谁（哪个Agent或模块）来执行？它们之间如何传递信息和决策？

2.2 脚手架的核心组件与设计原则

基于理论，我们可以抽象出一些通用的脚手架组件，并根据策略进行组合和定制：

1. 感知与表征Agent（Perception/Representation Agent）：

   • 职责：负责将原始、非结构化的输入（如用户描述的症状、日志文本、数据图表）转化为结构化的、机器可理解的问题陈述。这可能包括信息抽取、关键实体识别、关系构建。
   • 定制点：对于需要精确量化数据的诊断（如工程故障），该Agent需要集成数据解析能力；对于依赖语义理解的诊断（如文本分析），则需要强大的摘要和重述能力。
   • 实操心得：这个Agent的输出质量直接决定下游的成败。我们经常需要为其提供“思维链”（Chain-of-Thought）提示，让它不仅输出结构，还输出它做结构化时的置信度和理由，便于后续环节校验。

2. 假设生成Agent（Hypothesis Generation Agent）：

   • 职责：基于结构化的问题表征，利用领域知识库或内部推理，生成一个可能的原因列表。这是创造性的一步。
   • 定制点：策略不同，生成方式不同。“差异分析”要求尽可能全地枚举，可能依赖一个预定义的分类树；“假设演绎法”则可能更注重基于相似案例的类比推理。这个Agent需要访问高质量的知识源。
   • 注意事项：必须为生成的每个假设附上初始的、基于先验知识的概率或置信度分数，哪怕是很粗略的。这为后续的贝叶斯更新奠定基础。

3. 推理与规划Agent（Reasoning/Planning Agent）：

   • 职责：这是脚手架的大脑。它接收假设列表，并基于诊断策略，规划下一步的“探查动作”。在假设演绎法中，它负责为每个假设推导出可检验的推论；在差异分析中，它负责找出最能区分两个相似假设的关键问题或测试。
   • 定制点：这是最需要“理论注入”的部分。该Agent的提示词（Prompt）应明确编码所选诊断策略的规则。例如，“请基于假设演绎法，为以下三个可能故障点，分别列出两条最有效、成本最低的验证测试”。
   • 常见问题：LLM有时会生成不切实际或成本极高的验证步骤。需要在该Agent的提示词中加入约束条件，如“优先考虑可通过现有API获取数据的测试”、“避免提出需要停机24小时的检查”。

4. 执行与收集Agent（Execution/Information Gathering Agent）：

   • 职责：负责执行推理Agent规划的探查动作。这可能包括调用外部工具（如数据库查询、运行测试脚本、调用搜索引擎API）、向用户提出澄清性问题、或者从多模态输入中提取新信息。
   • 定制点：根据领域不同，需要集成不同的工具集。医疗诊断可能需要接入医学文献数据库和化验单解读工具；软件调试则需要接入日志系统、代码库和测试框架。
   • 实操心得：这个Agent的可靠性至关重要。必须为其设计完善的错误处理机制。例如，当API调用失败时，它应能提供清晰的错误信息给上游Agent，而不是让整个流程静默崩溃。

5. 评估与决策Agent（Evaluation/Decision Agent）：

   • 职责：整合新收集到的证据，按照贝叶斯更新或逻辑规则，重新评估所有假设的概率。判断是否已有假设达到终止阈值（如概率>95%），或者是否需要启动新一轮的“生成-推理-收集”循环。
   • 定制点：评估逻辑取决于策略。可以是简单的规则（如“排除被证据直接反驳的假设”），也可以是复杂的概率计算模型。LLM在此可以扮演“证据与假设关联性”的评估者。
   • 注意事项：要防止“确认偏误”（Confirmation Bias），即过度关注支持先入为主假设的证据。可以在提示词中明确要求其寻找反驳性证据，并定期引入一个“挑战者Agent”对当前最优假设进行批判性审视。

设计原则总结：脚手架不是固定不变的管道，而是一个动态的、由理论指导的认知过程模拟器。每个Agent都对应一个特定的认知功能，它们之间的交互协议（谁在何时、以何种格式、传递什么信息）必须紧密贴合目标诊断策略的步骤。

3. 从理论到实践：构建一个故障排查智能体

让我们以一个具体的场景为例：为一个云原生微服务系统构建一个自动化的故障根因定位智能体。我们将采用结合了“差异分析”和“假设演绎”的策略。

3.1 策略分析与脚手架选型

云服务故障通常表现为指标异常（如CPU飙升、延迟增加、错误率上升）。我们的策略是：

1. 初步差异分析：根据异常指标的模式（如哪个服务、哪个指标、突变形态），快速匹配到几类常见的故障根因大类（如代码Bug、资源不足、依赖服务故障、配置错误、网络问题）。
2. 假设演绎深入探查：在每个大类下，生成具体的假设（例如，“资源不足”大类下可能是“Pod内存Limit设置过低”或“节点内存耗尽”），然后设计针对性的检查命令或查询去验证。

对应的脚手架设计如下：

• 主控Agent（Orchestrator）：协调整个流程，维护诊断状态（当前假设集、证据集）。
• 表征Agent：输入是告警信息（如“Service-A的P99延迟在5分钟内从50ms升至500ms”）和相关的近期部署、变更信息。输出是一个结构化的故障描述JSON。
• 假设生成Agent：接收表征，首先调用一个“故障模式分类器”（一个经过微调或拥有领域知识的LLM），输出2-3个最可能的故障大类。然后，针对每个大类，再生成2-3个具体假设。
• 推理规划Agent：针对每个具体假设，规划验证步骤。例如，对于假设“是下游Service-B超时导致”，规划步骤为：1) 查询Service-A调用Service-B的当前错误率和延迟；2) 检查Service-B自身的健康状态。
• 执行Agent：拥有调用Kubernetes API、Prometheus查询语言（PromQL）、日志查询（如ELK）等工具的能力。执行规划好的步骤。
• 评估Agent：接收执行结果。使用规则引擎（如“如果调用Service-B的错误率>30%，则该假设可能性大增”）结合LLM对文本结果（如日志片段）的解读，更新假设概率。主控Agent根据评估结果，决定是确认某个假设，还是要求假设生成Agent在未排除的大类下生成更细粒度的假设。

3.2 核心环节实现细节

这里重点展示假设生成Agent和推理规划Agent的提示词设计，这是“理论注入”的关键。

假设生成Agent提示词示例：

你是一个资深的SRE专家，擅长进行系统故障的根因分析。请基于以下故障表征，进行第一轮差异分析。 ## 故障表征 {{ structured_fault_description }} ## 你的任务 1. 首先，从以下五大常见故障根因类别中，选出最相关的2-3个类别（按相关性排序）： - A. 资源不足（CPU、内存、磁盘I/O、网络带宽） - B. 服务依赖故障（下游服务超时、返回错误） - C. 应用代码缺陷（近期部署引入的Bug、内存泄漏） - D. 配置错误（配置文件、环境变量、服务发现） - E. 基础设施问题（网络分区、宿主机故障、存储卷异常） 2. 然后，针对你选出的每个类别，列举1-2个最可能的具体假设。每个假设请用一句话清晰描述。 3. 为你列出的每个具体假设，提供一个初始的置信度分数（0-100），基于该类别与当前故障模式的常见关联程度。 请以以下JSON格式输出： { "relevant_categories": [ {"category": "类别名", "confidence": 类别置信度, "specific_hypotheses": [ {"description": "具体假设描述", "initial_confidence": 具体假设置信度} ]} ] }

推理规划Agent提示词示例：

你是一个故障排查策略规划师。针对给定的具体故障假设，你需要设计最小化、可操作的验证步骤。 ## 当前待验证假设 {{ current_hypothesis_description }} ## 可用工具 - 查询Prometheus指标（PromQL） - 查询Kubernetes资源状态（kubectl get/describe） - 搜索最近1小时的应用日志（关键词搜索） - 检查服务依赖调用链（通过分布式追踪数据，如Jaeger） ## 你的任务 设计1-3个验证步骤。每个步骤必须： 1. 目标明确：直接针对假设的某个关键预测。 2. 可操作：明确指出使用哪个工具，以及具体的查询/命令是什么。 3. 成本低：优先选择能快速返回结果、对系统影响小的检查。 例如，对于假设“Pod内存Limit设置过低导致OOM重启”，一个验证步骤可以是： - 工具：`kubectl describe pod` - 命令/查询：`kubectl describe pod <pod-name> -n <namespace> | grep -A 5 -B 5 "OOM"` - 预期：如果找到OOMKilled事件，则支持该假设。 请输出一个JSON数组，每个元素是一个步骤对象。

注意：这些提示词需要在实际使用中不断迭代优化。关键在于让LLM扮演一个“遵循特定方法论的专业人士”，而不是自由发挥。输出的结构化格式（JSON）至关重要，这是Agent间可靠通信的基础。

3.3 工具集成与执行Agent实现

执行Agent是脚手架与真实世界交互的手和眼睛。它的实现需要扎实的工程能力。

# 一个简化的执行Agent工具调用示例 class ExecutionAgent: def __init__(self, prometheus_client, k8s_client, logging_client): self.tools = { "promql": prometheus_client.query, "kubectl_describe": k8s_client.describe_pod, "search_logs": logging_client.search, # ... 其他工具 } def execute_plan(self, plan_step): """ plan_step 结构: {"tool": "promql", "query": "up{job='service-b'}", "expected_evidence": "指标值为0表示服务下线"} """ tool_name = plan_step["tool"] command = plan_step["query"] if tool_name not in self.tools: return {"error": f"未知工具: {tool_name}"} try: # 调用实际工具 raw_result = self.tools[tool_name](command) # 对原始结果进行初步清洗和格式化，便于后续评估Agent理解 standardized_result = self._standardize_result(tool_name, raw_result) return {"success": True, "data": standardized_result} except Exception as e: # 详细的错误处理，将异常信息转化为上游能理解的证据 return {"success": False, "error": str(e), "data": None} def _standardize_result(self, tool_name, raw_data): # 将不同工具返回的数据格式统一为一种简单的文本或键值对格式 if tool_name == "promql": return str(raw_data) # 简化处理，实际可能需要提取数值 elif tool_name == "kubectl_describe": return raw_data # 假设已经是文本 # ...

实操心得：执行Agent的稳定性决定了整个系统的可靠性。一定要为每个工具调用设置超时和重试机制。此外，将原始工具输出“标准化”是一个容易被忽视但至关重要的步骤，它能极大降低评估Agent解析结果的难度。

4. 评估、迭代与系统优化

4.1 多轮迭代与终止条件

诊断很少一轮完成。我们的智能体系统需要支持多轮“生成-规划-执行-评估”的循环。主控Agent负责管理循环：

1. 状态管理：维护一个“假设池”，记录每个假设的当前置信度、支持证据和反驳证据。
2. 循环触发：评估Agent完成一轮评估后，如果没有假设的置信度超过“确认阈值”（如85%），并且置信度最高的几个假设之间差距小于“分化阈值”（如10%），则触发新一轮。
3. 新一轮的焦点：将当前“假设池”和所有历史证据传递给假设生成Agent，要求它“基于现有证据，对尚未排除的X类别，提出更深入或更具体的假设”。这模拟了专家在获得新信息后调整思考方向的过程。
4. 终止：当某个假设置信度超过确认阈值，或达到最大循环轮数（防止无限循环），或剩余所有假设的置信度都低于“排除阈值”（如5%）时，流程终止。输出最终结论、置信度及关键证据链。

4.2 效果评估与调优

如何评价这个“量体裁衣”的智能体好不好？不能只看最终诊断对不对，还要看过程。

• 诊断准确性：在历史故障数据集上，比较智能体最终结论与人工标注根因的一致性。
• 决策效率：平均需要多少轮循环、调用多少次工具才能得出结论？这对应着排查成本。
• 认知合理性：生成的假设序列、规划的验证步骤，是否符合领域专家的思维习惯？可以通过专家评审来评估。
• 可解释性：系统是否能提供清晰的证据链，说明为何提升或降低某个假设的置信度？

调优主要围绕两个层面：

1. 策略层调优：我们选择的诊断策略是否最适合该类问题？比如，对于非常罕见、无先例的故障，“差异分析”可能失效，需要切换到更侧重于“溯因推理”（Abductive Reasoning）的策略，即寻找能最好地解释所有异常现象的最简假设。
2. 实施层调优：各个Agent的提示词、工具集的完备性、证据评估的逻辑规则、置信度更新的算法参数等。这是一个需要大量实验和领域知识注入的过程。

4.3 常见陷阱与避坑指南

在实际构建这类系统时，我踩过不少坑，这里分享几个关键的：

• 陷阱一：过度依赖LLM的“直觉”，忽视确定性工具。

  • 现象：规划Agent设计了一个验证步骤：“请分析这段日志，判断是否有线程死锁的迹象”。这完全依赖LLM对文本的理解，结果可能不稳定。
  • 改进：应优先规划能通过确定性工具获取明确信号的步骤。比如，先通过“jstack”命令获取线程堆栈这个确定性信息，再将堆栈文本交给LLM分析。让LLM做它擅长的语义理解和推理，让传统工具做精确的数据采集和计算。

• 陷阱二：假设空间爆炸或过早收敛。

  • 现象：要么第一轮生成几十个不切实际的假设，拖慢系统；要么第一轮就武断地将置信度集中到一个错误假设上。
  • 改进：在假设生成Agent的提示词中，加入强约束（“仅考虑最近24小时内有变更的组件”、“优先考虑影响面与故障现象匹配度最高的原因”）。在评估Agent中，采用更保守的置信度更新算法（如平滑处理），并设置“最小假设保留数”，避免过早排除潜在正确选项。

• 陷阱三：证据评估的模糊性。

  • 现象：执行Agent返回“磁盘使用率85%”，这个证据对“磁盘已满导致IO阻塞”这个假设是强支持还是弱支持？需要阈值。
  • 改进：不要完全让LLM自由心证。构建一个“证据-假设关联强度”的知识库或规则库。例如，可以定义规则：如果磁盘使用率 > 90%，则对假设H的支持强度为强；如果在70%-90%，则为中；否则为弱`。LLM可以用来处理那些难以规则化的文本证据。

• 陷阱四：忽略行动成本。

  • 现象：规划Agent建议“重启服务以确认是否缓解”，这在生产环境可能是不可接受的高成本操作。
  • 改进：在规划Agent的提示词中明确列出“行动成本约束”，例如：“禁止提出会导致服务中断、数据丢失或性能显著下降的验证操作。优先选择只读的查询和检查。”

构建一个理论指导的、诊断策略定制的LLM智能体脚手架，是一个将人类专业领域知识、形式化的认知模型和LLM的强大能力相结合的过程。它没有通用捷径，需要深入理解你要解决的具体问题领域。但一旦构建成功，它将不仅仅是一个自动化工具，更是一个可解释、可迭代、能嵌入组织集体智慧的诊断专家系统。