本周工作概览

现在各个模块陆续完工，这周的任务是把所有东西捏在一起，跑通完整的“监控—分析—决策—执行—复盘”闭环，同时解决测试中暴露的各种问题。我主要负责Agent编排层的稳定性优化、工具调用的性能调优，以及和前端、监控、知识库三个方向的同学做密集联调。这周的bug数量比前五周加起来还多，但每修一个都让系统更健壮一点。

具体工作内容

典型故障场景的剧本测试

周一我们挑出了三个典型故障场景做端到端测试：数据库连接池耗尽、磁盘占用过高、接口错误率飙升。每个场景我都在Docker Compose环境里手动注入故障（比如用tc命令模拟网络延迟、用dd命令写满磁盘分区、用压测脚本打爆连接池），然后观察OpsPilot从收到告警到生成复盘报告的全过程。

数据库连接池耗尽这个场景跑出了意料之外的问题。Agent收到Alertmanager推送的告警后，第一步调用PromQL查询连接池活跃连接数曲线，这个查询需要avg_over_time聚合函数，时间窗口设为过去10分钟。但Prometheus返回的数据点步长是15秒，一个10分钟窗口有40个点，加上多个标签组合，返回的原始数据量接近800个数据点。我的PrometheusClient在降采样时把阈值设成了200，超过200才聚合，800个点直接传给了Agent。结果大模型接收到的上下文瞬间膨胀，响应时间从正常的5秒飙升到28秒，而且模型在处理这么密集的数据时开始“幻觉”——把某个时间点的数值重复解释了三次。

修复方案是把降采样阈值从200降低到100，并且强制要求工具返回时只输出统计摘要（最大值、最小值、平均值、变化斜率、异常时间窗口）而不是原始序列。同时我在工具内部增加了数据压缩逻辑，如果原始点超过100个，先按时间窗口聚合为每分钟一个点再计算摘要。修改后同样的查询返回给模型的文本从大约3000个token降到了400个token，响应时间回到6秒以内。

提示词工程的迭代优化

测试过程中发现Agent的行为有时不够稳定。比如同样是磁盘告警，有时候Agent会先查PromQL，有时候会直接检索知识库，导致分析路径不一致。我分析了十几个失败案例，发现根本原因是系统提示词里对工具调用顺序的描述太模糊，只写了“你可以使用以下工具”，没有明确优先级规则。

于是这周我对提示词做了三次大改。最终版本里明确规定了分析流程：第一步必须调用PromQL查询异常指标在过去30分钟的趋势，获取客观数据；第二步根据指标变化特征选择分支——如果是突增型故障则优先查日志找错误堆栈，如果是渐变型故障则优先检索知识库找历史案例；第三步只有在前面两步都无法定位时才调用服务状态检查工具。这个“先数据、后日志、再案例”的规则写进了提示词的开头，并且用加粗和示例强调。

另外我还加入了“反思机制”。每次Agent给出结论之前，我要求它在内部思考“我的结论是否有足够的证据支持？如果证据不足，还需要调用哪个工具？”这个反思步骤虽然增加了一次模型调用（大概多花1.5秒），但显著减少了瞎猜的情况。测试集上根因分析的正确率从72%提升到了84%。

工具调用超时与重试机制的压力测试

周三我们对整个系统做了压力测试。模拟场景是在一分钟内连续推送50条告警（告警风暴），观察Agent的编排层如何处理。结果发现两个问题：一是PromQL查询工具在并发请求下会出现连接池耗尽，因为每次查询都新建一个httpx.AsyncClient，没有复用连接；二是日志检索工具的超时设置是10秒，但Elasticsearch在负载高时偶尔需要15秒才能返回，导致大量超时失败。

我修改了PrometheusClient，把它改成一个单例模式，整个Agent会话复用同一个httpx.AsyncClient，并且把连接池大小从默认的10增加到50。修改后并发查询的等待时间减少了大约40%。对于日志检索超时的问题，我实现了指数退避重试机制：第一次超时后等1秒重试，第二次等2秒，第三次等4秒，最多重试3次。同时把默认超时从10秒调整为15秒，因为用户等待20秒以内是可以接受的，但频繁失败会打断分析流程。

重试机制还有一个细节：不是所有工具都适合重试。PromQL查询如果超时，大概率是Prometheus本身负载高，重试可能加重负担，所以这类查询超时后直接返回“数据暂时不可用”让Agent走知识库路线。而日志检索超时往往只是网络抖动，重试效果很好。

前后端接口的性能优化

前端同学反馈告警面板加载太慢，每次刷新需要先拉取告警列表，再对每个告警请求分析状态，串行下来耗时超过15秒。我分析了接口设计，发现当前的设计是前端调用/api/alerts拿到告警ID列表后，循环调用/api/analysis/session/{id}获取详情。这个模式在告警数量多时效率极低。

我新写了一个批量接口/api/alerts/with_summary，后端一次性返回所有告警的摘要信息，包括告警名称、严重程度、触发时间、当前分析状态（待分析/分析中/已完成/失败）以及已经生成的根因一句话摘要。这样前端只需要一个请求就能渲染告警列表，点击某条告警时才加载详细的trace数据。优化后首页加载时间从15秒降到了800毫秒。

另一个优化点是复盘报告的生成速度。之前生成报告时需要Agent重新遍历整个会话的所有消息，每次生成耗时10秒左右。我加了一个缓存机制：会话结束后自动预生成报告并存到Redis，键是report:{session_id}，有效期24小时。用户点击“生成复盘报告”时直接从缓存返回，响应时间从10秒变成300毫秒。如果缓存不存在（比如会话还没结束），再触发实时生成。

知识库检索准确率的调优

这周我花了一天时间做知识库检索的A/B测试。准备了20个查询问题（每个问题对应一个已知的故障案例），分别用纯向量检索、纯BM25检索、混合检索三种方式测试Top-3准确率。结果纯向量检索是70%，纯BM25只有55%，混合检索（向量召回10个再用BM25重排取前3）达到了85%。但85%还不够理想，分析错误案例发现大部分是查询中出现了专业术语（如“OOMKilled”、“throttling”）时向量检索会把语义相近但不相关的文档排到前面。

我引入了第二次重排：用一个轻量级的cross-encoder模型（BAAI/bge-reranker-base）对混合检索返回的Top-5文档重新打分。这个模型会同时看查询和文档的完整文本，计算一个相关性分数。虽然增加了大约200毫秒的延迟，但Top-3准确率从85%提升到了93%。考虑到每次检索的总耗时仍然控制在500毫秒以内，这个代价是值得的。

代码仓库整理与文档补充

按照项目计划要求，这周我开始整理代码仓库的文档。写了三个主要文档：DEPLOYMENT.md（从零开始用docker-compose部署整个系统的步骤）、API_REFERENCE.md（后端所有接口的请求响应格式说明）、AGENT_PROMPTS.md（系统中所有提示词模板的版本记录和设计思路）。另外把之前散落在各个文件夹里的测试脚本统一挪到了scripts/目录，并给每个脚本加了注释说明用途。

文档写作过程中发现代码里有几个硬编码的配置（比如Prometheus的URL写死在config.py里），我改成了从环境变量读取，并在docker-compose.yml里提供了默认值。这样其他人部署时只需要修改.env文件，不用改代码。

本周遇到的问题与解决

这周最难排查的一个问题是：某个测试场景中Agent分析到一半就停止响应，没有报错也没有返回结果。我加了详细日志后发现是图编排引擎的死锁——parallel_query节点在等待所有并发工具返回，但其中一个工具（状态检查）因为网络问题永远没有返回，而超时机制只在工具层有，编排层没有设置总超时。解决方案是在parallel_query节点加了一个asyncio.wait_for，总超时30秒，超时后未完成的工具标记为失败，已完成的工具结果继续使用。这样至少部分数据能用，Agent可以给出带局限性的结论。

另一个问题是和前端联调时发现Agent的思考过程在时间线上有时会乱序。排查原因是trace记录的timestamp是在节点开始时生成的，但异步执行导致实际结束时间晚于下一个节点的开始时间。我改成每个节点结束时生成trace记录，并用结束时间作为排序依据，前端展示时按照结束时间顺序渲染。