任晶磊-面向API测试垂类应用的专家智能体与LLM工程优化.pdf

1、面向API测试垂类应用的“专家”智能体与LLM工程优化任晶磊|思码逸任晶磊思码逸创始人兼 CEO清华大学计算机系博士；前微软研究院研究员，斯坦福大学访问学者多篇论文发表在 FSE、OSDI 等顶级国际会议上曾参与微软下一代服务器系统架构设计，获 4 项美国发明专利软件研发效能度量规范标准核心起草专家参与编著软件研发效能权威指南软件研发效能提升实践研发大数据平台 Apache DevLake 开源项目发起人目 录CONTENTSI.四个根本的选择II.技术挑战视角：问题与方案III.架构组织视角：“混合多专家”IV.系统演进视角：项目历史回顾V.总结与展望Bonus：大模型时代的技术意识“技术深

2、度不够，需要补充系统架构”How do you build a moat in consumer AI?Right now,sorry to say,there is none.传统意义上的“护城河”正在消失，速度与势能正在取而代之。大模型实现知识平权，智能体实现技能平权。四个根本的选择PART 01选择一：GUI 测试 vs.API 测试结论：长期看好 API 测试的价值，值得投入资源进行智能化探索GUI 测试 端到端质量验证，应用广泛；可以没有 API 测试，但极少不做 GUI 测试 oGUI 可能迎来技术变革：on-demand 动态前端意味着新的测试模式API 测试 随着 LLM 发展

3、，API 层会更加重要，包括 MCP 接口形式 如果项目还没有做或者不重视 API 测试，应开始行动，投入建设 API 文档提供结构化信息，验证模式简单选择二：Copilot 辅助 vs.Agent 交付结论：选择交付最终结果，减少对人的干扰，只关注确定的价值Copilot 辅助 人可以及时处理生成中的问题，补充缺失知识，实时看到成果o需要人同步接管全程，投入时间多，提效不确定Agent 交付 异步实现，人只需要 review 成功通过的用例和脚本，投入时间少，收益明确o如果要处理生成中的问题，等待久，无法实时干预借鉴 Meta 生成单元测试的实践选择三：通用智能体 vs.垂类智能体结论：通用

4、智能体效果欠佳主要不是大模型能力的短板，而是没有结合垂类应用的 know-how问题：通用智能体能实现 API 测试吗？把各种依赖实现为 MCP 有意义吗？选择四：优先哪些知识源获取成本分析难度可用性总分API 文档8人工输入7调用日志6代码理解6需求/产品档5结论：按综合优先级接入系统，API 文档 人工输入 调用日志 代码理解 需求/产品文档技术挑战视角：问题与方案PART 02挑战一：API 关系准确性目标：准确还原 API 之间的调用关系与语义依赖，为后续用例和脚本生成提供可靠上下文APItagrefers_torelated_tohas_taghas_path解决方案多端知识库向量端

5、：Milvus 存储 API 描述的文本向量，用于语义相似检索图谱端：NetworkX Neo4j 有向图存储逐步升级键值端：JSON KV 用于存放原始文档与增量 diff跨文件关系抽取：跨 OpenAPI 文件的引用、实体关系增量关系构建：差量处理有变更的节点，避免整库重建动态多层构建机制及预处理按需逐层构建 API 关系图，避免一次性处理所有关系预处理异步任务（处理过程中暂不支持数据查询）挑战二：文档知识容错目标：在文档缺漏、与实际代码不一致甚至示例错误时，仍能稳定生成可执行的测试脚本解决方案核心：形成知识迭代执行完一批测试后，自动摘要新增业务知识（如正确的输入参数格式、数据依赖关系等）

6、交互式知识编辑：允许测试人员直接补充、修改 API 级知识文档质量诊断：识别文档中的问题并给出改进建议15 种错误分类模板“及时止损”：判断问题性质，避免浪费例如数据既无法自行构造，也无法从其他 API 获取时，应该果断中止探索过程挑战三：生成可执行代码目标：生成测试脚本可在测试环境执行通过，包括正确的鉴权、参数构造、断言等解决方案多阶段生成流程采用“文本用例代码生成”两阶段（可类比 Manus 等的 TODO list）引入 step actor，将测试生成分解为多个专门的步骤（API 发现、参数构造、断言生成等）隔离执行+反馈学习Docker Sandbox+子进程超时，防止挂死收集 st