pdf版下载链：https://pan.quark.cn/s/9cc742e9c2a8

15 AI 应用架构高级专题：多 Agent、推理优化与系统演进

更新： 2026-10-12
难度： ⭐⭐⭐⭐⭐
考点： 多模态、Agent Harness、沙箱、长任务、评测、权限、成本与系统演进

📋 目录

1. 多模态 AI 应用
2. 自主 Agent 与 Agentic Workflow
3. AI 产品与企业架构
4. 调试、评测与 Harness
5. 推理和持续改进
6. 官方来源

一、多模态 AI 应用

Q1: 如何处理多模态输入（图片 + 文字）？举例说明应用场景。

先明确任务类型，再决定走原生多模态模型、专用模型，还是混合流水线：

生产要点：

• 记录图片哈希、尺寸、裁剪区域、模型版本和 Prompt 版本。
• 对坐标、金额、日期等做程序校验，不只相信自然语言。
• 敏感图片先脱敏；第三方模型调用遵守数据区域与保留策略。
• 失败时保留 OCR 文本、视觉证据和原图引用，便于排障。

Q2: 多模态应用如何优化性能和成本？

稳定选型维度：

1. 输入减量：缩放、裁剪、分帧抽样、去重。
2. 级联路由：轻量 OCR/CV 先处理，难例再交给大模型。
3. 并行与批处理：页面并行、Embedding 批处理、异步队列。
4. 缓存：按内容哈希缓存解析和模型结果，加入版本键。
5. 结构化输出：Schema 校验后重试局部字段，不重跑整份文档。
6. 质量预算：按文档类型分别设准确率、延迟和单件成本，不承诺无依据的固定节省比例。

二、自主 Agent 与 Agentic Workflow

Q3: 什么是 Agentic Workflow？和传统 AI 应用有什么区别？

Agentic Workflow 让模型在受控循环中根据观察选择下一步工具：

目标 → 计划/选择动作 → 工具执行 → 观察 → 校验 → 继续或结束

“自主”不等于无限权限。Agent 的自主性应被 Harness 的工具白名单、沙箱、预算、审批和终止条件约束。

Q4: 如何设计一个自主编程 Agent？

核心不是换一个更强模型，而是搭好 Harness：

任务澄清
→ 仓库探索
→ 计划和风险识别
→ 在隔离工作区修改
→ lint / build / test
→ 根据证据修复
→ diff 审查
→ 人工批准提交/PR

必要模块：

• 仓库检索和上下文选择；
• 文件编辑与 patch；
• shell、测试和静态分析；
• Git worktree/容器隔离；
• 超时、最大步数、重试和成本预算；
• 检查点、事件日志和可恢复状态；
• 权限策略与高风险审批。

结束条件应由可验证证据驱动，例如“目标测试通过且无新增 lint 错误”，而不是模型说“已完成”。

Q5: 多 Agent 协作系统怎么设计？

只有职责、上下文或权限边界确实不同，才值得拆多 Agent。

常见模式：

• Manager/Workers：协调者拆分独立子任务。
• Pipeline：研究 → 实现 → 测试 → 审查。
• Parallel Candidates：并行产出多个候选，由确定性测试或评审选优。
• Specialized Agents：每个 Agent 使用不同工具和最小权限。

关键工程问题：

• 共享状态以 artifact/事件为主，不靠复制完整对话。
• 每个子任务有输入、输出、owner、deadline、budget、idempotency key。
• 避免多个 Agent 同时修改同一工作区；使用 worktree/分支。
• 聚合时保留证据和失败，不让协调者把分歧“总结没了”。

三、AI 产品思维与架构设计

Q6: 如何判断一个场景是否适合用 AI？

用六维框架：

1. 任务可验证性：是否能定义正确、错误和人工兜底。
2. 数据与权限：数据是否可用、合规、可授权。
3. 容错性：错误是否可逆，是否影响资金、安全、法律责任。
4. 经济性：相对规则系统和人工流程的总拥有成本。
5. 体验：延迟、不确定性和交互成本是否可接受。
6. 持续评测：能否建立离线集、线上指标和 badcase 回流。

规则明确且要求强一致的任务优先传统程序；AI 适合规则难穷举、输出可验证、失败可兜底的任务。

Q7: 设计企业级 AI 应用架构，需要考虑哪些方面？

客户端
→ API Gateway / IAM
→ Orchestrator / Agent Harness
→ Model Gateway + RAG + Tools/MCP
→ 业务服务与数据
→ Tracing / Evals / Audit / Cost

回答至少覆盖：

• 质量：模型/Prompt/索引版本和回归集。
• 可靠性：timeout、retry、idempotency、circuit breaker、fallback。
• 安全：tenant filter、secret、sandbox、approval、egress。
• 可观测：trace 贯穿模型、检索、工具、审批和最终结果。
• 成本：模型路由、缓存、上下文预算、并发和配额。
• 变更：灰度、A/B、可回滚配置和版本固定。

Q8: RAG、Agent、MCP、A2A 如何协同？

它们不是固定“四层黄金架构”，而是解决不同问题的可选组件：

截至 2026-10-12，A2A v1.0 的核心抽象包括 Message、Task、Artifact 和 task lifecycle。简单场景优先单 Agent；跨团队、跨权限域或长任务服务化时，再考虑 A2A。

四、AI 应用调试与评测

Q9: AI 应用出现问题，如何系统排查？

先用同一个 trace ID 串起：

输入 → 路由 → 检索 → Prompt → 模型 → 工具 → 状态 → 输出

排查顺序：

1. 固定输入、模型快照、配置和随机性，稳定复现。
2. 判断是数据、检索、模型、工具、Harness 还是 UI 拼接。
3. 看原始事件流，不只看最终文本。
4. 用最小案例验证假设。
5. 修复后加入回归集，灰度观察线上指标。

Agent 额外检查：重复动作、无进展循环、权限拒绝、超时、取消、状态恢复和并发冲突。

Q10: 如何调试和优化 Prompt？

Prompt 优化必须建立在 eval 上：

1. 从真实 badcase 建立版本化数据集。
2. 定义可执行评分：schema、引用、工具结果、业务规则、人工 rubric。
3. 固定其他变量，比较 Prompt 变体。
4. 同时看均值、尾部、失败类型、延迟和成本。
5. 对通过离线门槛的版本做小流量灰度。

Few-shot、角色或“逐步思考”不是必然增益。对推理模型，更应给清晰目标、证据和验收条件，不要求暴露私有思维链。

Q11: 2026 年 AI 应用开发更值得关注哪些方向？

比产品新闻更稳定的方向：

• 长任务：持久化状态、恢复、取消、人工输入。
• Skills：可版本化、可评测、按需加载的工作流。
• Harness：确定性控制与模型决策结合。
• 沙箱和权限：workspace、网络、密钥、审批分层。
• Agent eval：轨迹、任务结果、安全和成本联合评测。
• 多模态执行：截图/DOM/终端/代码 artifact 联合。
• 协议互操作：MCP 工具连接、A2A 任务委托。

五、Harness、奖励与推理控制

Q12: 什么是 Harness Hill-Climbing？为什么比追逐单次产品更新更重要？

Harness 是模型外部的执行骨架：Prompt、工具、检索、状态、策略、沙箱、审批、重试和终止条件。

Harness Hill-Climbing 指以 eval 为反馈，小步修改 Harness：

建立基线 → 只改一个因素 → 跑回归集 → 分析失败
→ 保留真实增益 → 线上灰度 → 回流新 badcase

常见可优化变量：

• 工具描述与 schema；
• 上下文选择和压缩；
• 计划是否显式；
• 测试/验证顺序；
• 最大步数和重试策略；
• 审批阈值；
• 模型路由与 effort。

不要把某篇博客的版本号当成能力保证。真正可迁移的能力是构建数据集、读取轨迹和用统计证据迭代。

Q13: Process Reward Model（PRM）和结果评测有什么区别？

• Outcome/Result evaluation：最终任务是否完成，例如测试通过、答案正确。
• Process evaluation：轨迹中的关键步骤是否合理，例如检索到证据、调用正确工具、没有越权。

PRM 可用于搜索、候选排序或训练，但生产 Agent 不一定需要单独训练 PRM。更常见的工程方案是：

• 确定性步骤断言；
• LLM-as-judge rubric；
• tool/trace validator；
• 最终业务结果和人工抽检。

过程分高不代表结果一定对，结果偶然对也不代表过程安全。两者应联合评估，并避免要求或存储模型私有思维链；评估可观察动作、证据和状态变化。

Q14: Agent 如何实现“持续改进”而不陷入未经验证的自我进化？

把新闻式 “Evolver/GEP” 降级为研究方向。生产系统应采用受控闭环：

1. 收集失败轨迹并脱敏。
2. 分类根因：模型、上下文、工具、权限、数据、Harness。
3. 生成候选修改，但不直接覆盖生产。
4. 在冻结评测集和安全集上验证。
5. 由人审批，版本化发布，可回滚。
6. 防止训练集/评测集污染和奖励投机。

可沉淀为 Skill、规则、测试、工具脚本或数据修复。没有评测门和发布治理的“自我修改”不是持续学习，而是不可控配置漂移。

Q15: Extended Thinking / Reasoning Effort 如何控制？

不同厂商接口已经分化，不能再统一写成固定 budget_tokens：

• Anthropic 新模型推荐 adaptive thinking，并用 effort 软控制深度；max_tokens 是思考加答案的硬上限。部分新模型已移除手工 budget_tokens。
• Gemini 3 系列使用 thinking_level；Gemini 2.5 仍使用模型相关的 thinkingBudget。
• OpenAI 推理模型使用模型/API 对应的 reasoning effort 等配置，需查目标模型文档。

生产策略：

• 简单分类、抽取走低 effort 或小模型。
• 复杂代码、规划按 eval 选择更高 effort。
• 同时监控成功率、TTFT、总延迟、输出截断和成本。
• 不假设相同 effort 在不同模型间等价。

速记卡片