接口不规范、没有现成 SDK 时 Agent 怎么办？
- 现场: 外部服务文档缺失、返回格式非标准、字段随版本漂移;
- 做法: 不等别人预先写好适配层，而是当场阅读接口文档或观察一两条真实响应，即时生成适配代码;
- 适配内容: 构造 HTTP 客户端、拼装鉴权头、解析非标准的返回结构、把上游数据模型转成下游可用格式;
- 定位: 代码成了连接任意系统的“万能胶”——哪里接不上就现场生成一段补上;
- 归属: 这是元能力中“系统接口”方向的核心，见 代码作为元能力;
外部系统完全没有 API 怎么办？
- 路径: 先用 Computer Use 操作图形界面，把成功完成的操作序列用代码固化为 RPA 工具;
- 收益: 未来执行相同任务时直接运行代码，以极高速度与稳定性完成，无需再调用昂贵的视觉思考;
- 定位: RPA 是“系统适配器”在无接口系统上的极端形态;
- 关联: Computer Use 的交互机制见交互扩展章节，工作流录制与固化的机制见持续进化章节;
为什么数据格式演化让手写解析不可持续？
- 现象: 同一系统在演化中可能多次修改数据格式——添加新字段、改变嵌套结构、引入新类型;
- 代价: 为每种格式手写解析代码，每次改动都要更新解析逻辑、测试兼容性、部署新版本;
- 新思路: 让 Agent 遇到新格式时基于样本数据临时生成解析代码，系统自动适应格式演化，无需人工干预;
日志可视化系统如何自适应格式演化？
- 挑战一: 不同工具返回不同结构的数据，格式随系统迭代不断演化;
- 挑战二: 一个完整轨迹可能包含数十万字符，需在概览与细节之间平衡;
- 循环: 前端遇到无法解析的日志格式时不显示错误，而是把失败信息（原始日志样本、详细报错）报告给 Agent;
- 步骤: Agent 分析样本数据结构并生成能正确解析的前端代码 → 代码先在虚拟浏览器中自动测试（验证解析正确性，用 Vision LLM 检查可视化效果）→ 通过后热更新到前端系统;
- 性质: 全流程自动化，系统因此能自我进化;
生产日志如何自动变成工单？
- 难点一: 任务失败可能由多个模块的协同错误导致，问题定位困难;
- 难点二: 生产环境复杂性难以在测试环境复现，复现成本高;
- 难点三: 缺乏系统化回归测试，已修复的问题容易反复出现;
- 分析输入: 生产轨迹集合 + 系统架构文档 + PRD（产品需求文档）;
- 输出一: 判断执行流程是否符合预期，定位有问题的环节与模块;
- 输出二: 结构化问题报告（优先级、模块、描述、改进建议）;
- 输出三: 回归测试用例——引用问题轨迹 ID 与关键交互轮次，测试框架通过自动重放验证修复后系统在相同输入下能否产生正确行为;
- 闭环: 通过 MCP 对接 GitHub，创建 Issue 并分配给相关开发者，完成从问题发现到任务分派的全自动化;