在本地跑通一个包含语音识别（STT）、视觉分析、LLM 推理与语音合成（TTS）的多模态 Agent 环境，往往会在环境配置上浪费整整三天。“CUDA driver version is insufficient”、“PyTorch compiled with CUDA 11.8 but found 12.1”、“WebSocket connection closed abnormally”……这

用户投诉比线上监控告警先到，这是大模型应用上线后最让人头疼的事情。过去做传统软件服务，巡检的核心指标非常清晰：HTTP 200 响应率、P99 延迟、CPU 内存占用。然而大模型应用（Prompt + LLM）上线后，即使所有 API 的 HTTP 状态码全是 200，响应延迟也完全正常，输出的语义质量却可能已经在暗中发生了严重的坍塌。大模型 API 供应商常常会静默更新底层模型版本（例如从升到团

告警群里的 API 扣费通知在半小时内响了上千次。单次调用费用从几分钱突然飙升到单小时数百美金。当时线上正在运行一个处理客服多模态工单的 AI Agent 系统。该 Agent 负责读取用户上传的故障截图与文本描述，通过 Tool Calling 调用内部查询接口并自动回复。然而某个边缘场景下，图像识别返回了一个格式微小的错误，Agent 在理解这个报错时陷入了自推导死循环：不断尝试调用查询工具、

注：本文只讨论验证方法。阈值应由当前模型、样本和监控记录共同确定。实验室里拿 100 条样本测出来的 99% 提取准确率，一旦放到高并发线上环境，往往会显著下降。把离线文档解析改为由大模型输出结构化内容时，少量示例提示词可能在小样本上看起来可用，却未必覆盖长文本、嵌套表格和格式噪声。先把输入长度、结构校验失败类型和重试次数记录下来，再决定提示词能否单独承担格式约束。

多模态 Agent 在引入视觉理解能力后，能够处理图表、网页截图和现场照片，大幅拓宽了应用边界。但在架构评审时，团队如果只停留在“能不能识别图片内容”的演示效果上，很容易忽视多模态接入后带来的计算资源暴涨与安全性漏洞。与纯文本 Agent 相比，视觉输入的非确定性与计算复杂度高出一个数量级。评审阶段必须把显存开销、图像 Prompt 注入和状态机死锁等隐性风险搬到桌面上。

多模态 Agent 在引入视觉理解能力后，能够处理图表、网页截图和现场照片，大幅拓宽了应用边界。但在架构评审时，团队如果只停留在“能不能识别图片内容”的演示效果上，很容易忽视多模态接入后带来的计算资源暴涨与安全性漏洞。与纯文本 Agent 相比，视觉输入的非确定性与计算复杂度高出一个数量级。评审阶段必须把显存开销、图像 Prompt 注入和状态机死锁等隐性风险搬到桌面上。

在设计 AI Agent 系统时，很多团队刚立项就试图构建一个复杂的 Multi-Agent 协作网络。他们把系统拆分成规划者（Planner）、执行者（Worker）、批评者（Critic）等五六个不同的智能体角色，甚至设计了繁琐的图状态路由。然而在工程落地的初期，盲目增加 Agent 数量往往带来难以控制的非确定性与极高的 Token 耗费。真正的工程之道，是从一个单圈 ReAct 循环的最小

许多团队在做深度学习框架选型时，往往只关注训练阶段的易用性和离线 Benchmark，却忽视了模型发布后的线上持续观察与可观测性体系构建。无论是将 TensorFlow 模型导出为 SavedModel 部署在 TF Serving，还是导出为 ONNX 并部署在 PyTorch/Triton 体系中，模型上线那一刻，绝不意味着工程交付的结束，而是线上持续监控的开始。

刚接手一个新的深度学习分类任务时，不少新人容易陷入两个极端：要么一上来就套用最复杂的 SOTA 模型架构，并手动尝试各种随机超参数；要么盲目使用贝叶斯优化网格搜索，跑了三天三夜才发现数据集里包含了大量损坏的无效图像。做模型调优，最忌讳“拿着锤子找钉子”。正确的工程路线，应当是从打通极简的 Baseline 链路开始，再借助自动化与可观测性手段逐步逼近性能极限。

模型小版本迭代后，Agent 的工具调用行为可能漂移。例如，带表格截图的提示词可能不再触发，而输出未经验证的文本。发布前应将这类场景纳入回归测试。模型提供商的模型权重稍有调整，Agent 的行为模式就可能发生不可预测的漂移。版本更新后，不能泛泛地做人工抽测，必须建立一套针对 Agent 关键能力缺陷的优先测试序列。