1. 项目概述:自进化智能体的技术突围
去年九月的一个深夜,我和团队在会议室白板前画下第17版架构图时,突然意识到我们正在触碰AI领域最前沿的命题——如何让智能体像人类一样,在完成任务的过程中持续进化。这就是Yunjue Agent的起点:一个能在执行开放域任务时自主扩展工具库的智能系统。
与传统AI系统不同,Yunjue Agent的核心突破在于实现了"原位自进化"(In-Situ Self-Evolving)。想象一位外科医生,传统AI好比需要定期返校培训,而我们的系统则能在每台手术中自动精进技艺。这种进化发生在真实任务场景中,无需暂停服务进行离线训练,这对需要7×24小时稳定运行的商业系统至关重要。
2. 技术架构解析
2.1 核心设计理念
我们构建的系统基于三个关键认知:
- 工具决定能力边界:再优秀的规划能力,没有适配工具也无法完成任务
- 进化需要即时反馈:工具调用成功与否提供了最明确的优化信号
- 知识必须可沉淀:每个任务积累的经验应转化为可迁移的通用能力
这种设计使得系统在HLE等需要复杂检索推理的任务中,相比Gemini 3 Pro等基础模型能提升十余个百分点准确率。
2.2 系统演进历程
初始版本(V0.1)采用了典型的"规划-执行"架构:
code复制[Planner] → [Agent Builder] → [Worker]
↑ ↓
[Memory] ← [Tool Pool]
但在实测中暴露出四大问题:
- 过度拆解:GPT-5会将简单任务分解出冗余验证步骤
- 单测失效:工具测试通过率虚高(达92%)
- 角色冲突:Worker同时承担执行和工具评估职责
- 串行瓶颈:平均每个任务耗时超过3分钟
经过六次迭代后,最终架构简化为:
code复制[Manager] → [Worker] → [Analyzer]
↑ ↓
[Tool Library] ← [Feedback]
这个看似简单的架构蕴含着关键创新:
- 动态工具生成:Analyzer实时诊断失败原因,触发工具迭代
- 批量并行处理:引入batch机制提升吞吐量5-7倍
- 去中心化决策:各模块专注单一职责,避免"脑裂"现象
3. 关键技术实现
3.1 工具自进化机制
工具库的进化遵循"发现-创造-验证-沉淀"四步循环:
- 需求发现:Worker执行失败时,Analyzer会识别缺失能力
- 工具生成:Manager根据错误类型动态创建新工具
- 即时验证:新工具立即投入下次任务尝试
- 知识沉淀:通过3次成功调用的工具进入稳定库
我们设计了工具收敛指标EGL(Evolutionary Generality Loss):
code复制EGL = 新工具创建次数 / 工具调用总次数
在HLE数据集上,EGL从初始0.38降至0.05,表明系统已形成稳定能力集。
3.2 工程实践挑战
实际部署中遇到的核心难题及解决方案:
| 问题类型 | 具体表现 | 解决方案 |
|---|---|---|
| API稳定性 | 请求超时率达15% | 构建多供应商混池 + 本地重试机制 |
| 网络延迟 | 搜索类任务响应超时 | 部署美国中继节点集群 |
| 内容审核 | Gemini返回空响应 | 引入消息回滚机制 |
| 成本控制 | GPT-5长上下文消耗大 | 实现动态上下文窗口调整 |
特别值得分享的是工具验证环节的优化:初期采用预生成测试用例的方式,不仅耗时(平均增加2.3秒延迟),且测试覆盖率不足。改为"线上验证"模式后,新工具立即投入真实任务检验,失败时触发"工具增强"流程,这使得工具迭代速度提升4倍。
4. 模型选型与调优
4.1 主流模型实测对比
我们在五个基准测试中对比了六类模型表现:
| 模型 | 工具调用准确率 | 长上下文稳定性 | 适合场景 |
|---|---|---|---|
| GPT-5 | 92% | ★★★★☆ | 复杂逻辑拆解 |
| Gemini 3 Pro | 88% | ★★☆☆☆ | 多模态任务 |
| Claude 4.5 | 85% | ★★★☆☆ | 创造性任务 |
| Kimi K2 | 72% | ★☆☆☆☆ | 中文简单任务 |
| MiniMax M2 | 68% | ★★☆☆☆ | 低成本场景 |
4.2 Prompt工程心得
经过数百次调整,我们总结出工具类prompt的黄金结构:
- 角色定位:明确系统各模块的职责边界
- 失败案例:包含典型错误示例比成功示例更有效
- 约束条件:必须用"必须/禁止"等绝对化表述
- 输出模板:强制要求JSON结构化返回
例如给Manager的prompt会强调:
"当Analyzer报告'缺少XX能力'时,你必须:
- 首先检查现有工具是否可通过组合解决
- 新工具描述必须包含输入输出示例
- 禁止创建功能重复的工具"
5. 典型问题排查指南
5.1 工具泛滥问题
现象:工具库持续膨胀但调用率低
诊断:EGL>0.2持续不下降
解决方案:
- 检查Analyzer的需求判断阈值是否过低
- 在Manager添加工具相似度检测
- 设置工具"退休"机制(30天未调用自动归档)
5.2 执行死循环
现象:同一任务反复尝试不同工具
诊断:单个任务耗时超过平均3倍
解决方案:
- 引入最大尝试次数限制(默认5次)
- 添加循环检测模式(相同错误出现3次触发报警)
- 人工干预标记"不可解任务"
6. 实际部署建议
对于想要尝试类似系统的团队,建议从三个维度准备:
硬件层面:
- 至少2台美国区域GPU服务器(避免API延迟)
- 搭建冗余网络通道(主备线路自动切换)
- 实施请求限流(防止突发流量击穿预算)
工程层面:
- 使用LangGraph等框架管理状态
- 为每个会话保持独立上下文存储
- 实现完整的执行轨迹日志系统
算法层面:
- 先从单一垂直领域验证核心机制
- 建立完善的回归测试集
- 设计可视化监控面板(实时显示EGL等指标)
这个项目的最大收获是验证了"工具优先"的进化路径确实可行。在金融检索任务中,系统自主开发的"财报关键指标提取器"后来被证明在医疗报告分析中同样有效,这种跨领域迁移能力令人惊喜。不过更让我意外的是,最终稳定版本的工具库规模(47个核心工具)远小于预期,说明智能体确实能发展出高度通用的基础能力。
