手里拿到一个活，要利用agent将监控数据汇总出来形成每日报告，所以用上了内部一个agent编排平台。这个平台还算方便，不需要写任何一行代码就可以制作出一个agent。

前情提要

我有什么？

我有获取数据的mcp、agent编排框架和大模型接口（花的是我自己的内网额度，要被榨干了）。agent编排框架能力有限，与agent相关的能力基本只有mcp接入、skills加入、子agent加入（只能有一层子agent，且子agent不能再套子agent）以及工具管理。

我要干什么？

读取数据，分析趋势，将一个窗口的数据（可能6小时到24小时）与它前一天的数据做比较，分析出是否有异常，判断异常集中发生的时间点来判断系统情况。

方案

初版

有主agent负责挑选数据（挑选策略是固定的，即某些特定的数据），然后将24h窗口内的监控数据分批次发放给子agent进行处理，子agent获取所有数据将数据变化趋势毫无保留的发送给主agent，主agent再对数据进行分析、汇总。

下面讲讲最先踩到的几个坑。

1. 子agent流程太长，有些数据可以由主agent解决，直接给到子agent，比如获取当前时间、数据源名称等等。这些虽然节省的上下文不多，但是很省时间。

2. 子agent对工作区内容操作造成了数据竞争，创建的文件名一模一样导致同一个文件的写造成读失效。这其实涉及到agent间通信的技术，但我选择了最简单粗暴的方法解决，就是子agent在创建文件时要带上一个唯一id（可以是这批次的数据源）

3. mcp上游限流导致请求失败后重试时间太长。这个其实可以借鉴计算机科学经典的思想————指数退避策略，最后发现确实有效解决了问题。agent里很多思想其实都是从传统计算机科学抄袭过去的。

4. 数据量太大，上下文膨胀严重。简单粗暴的方法：缩小数据窗口，从24h变为12h。降低数据采样率，原来可能采集窗口内每分钟的数据，现在改为采集每10分钟的数据

第一次迭代后

这样来看其实agent已经初步成型，但是遇到了最难的一个问题，即整个任务下来耗时达到了不可接受的地步，最长的一次需要4h。一开始怀疑是大模型api上游在限流，但是感谢我司内部的LLM调用监控工具，我发现模型输出速度其实没有什么问题，速度慢是上下文雪崩导致的。

所以我又解决了一些问题。

1. 我发现mcp获取到的数据会全部进入agent的上下文，这绝对是造成上下文雪崩的主要因素（毕竟数据量超级无敌大）。于是数据分析的能力不可以交给LLM，需要“下放”给python脚本，这下就必须用正则语言来做数据分析了。老实说，数据分析这块我是几乎一窍不通，所以只能信任claude opus 4.8了。

2. 主agent分析容易出现幻觉，对数据胡编乱造。发现可能跟子agent返回给主agent的消息参杂了大量数据导致的（仍然是上下文膨胀的问题），原来子agent会将所有有可能有问题的数据点返回给主agent，最后主agent上下文膨胀，分析的幻觉率就变得很高。所以我将分析数据的能力下放到子agent，子agent直接分析并总结，将总结内容发回给主agent，由主agent对内容做关联性分析。

3. 数据分析的结果不够准确，依旧会幻觉。这个问题是最好解决的，直接给我上最贵最好的模型，claude opus 4.8启动（其实几个小时前我才听说kimi k3起飞了）。玩笑归玩笑，数据分析的python脚本其实也是关键，这个如果写的不好，会直接影响结果，所以仍然需要继续迭代。

第二次迭代后

现在agent已经初步具备了拿到数据并分析的能力。是啊，我费了这么大劲他才刚刚能勉强做到这点，现在仍然存在的问题有：分析效果不够好、时长有可优化空间（跑一次大概半小时）、价格太贵（跑一次50块）。所以，我进一步加强了脚本的覆盖范围，尝试将大部分逻辑都写入脚本，来保证数据分析的正确性，也可以减少token的使用量。但是这会带来副作用，有写脚本写死的输入变量如果被agent误解，那么整个子任务就会直接失败。于是，又得把更多的能力下放回LLM。这次我的策略也变得更加简单且直接：

1. 进一步缩小窗口，减小模型上下文体积

2. 简化分析策略，不做复杂性分析，只判断与前一天产生差异的时间和大小，直接取消掉了复杂的分析脚本，只保留了数据处理的脚本。

3. 再次简化返回格式，返回消息只包含产生问题时间点的概述。

截止目前

现在这个跑定时监控任务的agent终于有了基本的、正确的分析能力，也能针对异常时间点做归因分析，即便归因的方式或许与业务实际逻辑有所出入。一个专用agent的编排确实很需要时间和精力，即便公司内部平台已经将我们从代码中解放出来，但难的根本不是代码逻辑，而是对于LLM调教是否能够贴合业务与需求。