每题：结论 → 分点 → 图（第 4、9 题）
| 你的处境 | 该选 |
|---|---|
| 知识库和工具已就绪，失败集中在「想不明白」 | 更强模型 |
| 模型够强，但接不到系统/数据 | 更多工具 |
| 任务开放、数据杂、口径不统一（大多数企业场景） | 更丰富的上下文 |
一句话判据：工具决定「能不能碰到」，模型决定「单步想得对不对」，上下文决定「有没有可用的信息」。前两个都能买，第三个只能自己建。
| 类型 | 表现 |
|---|---|
| 空结果当成功 | 工具返回 []/null，模型认为完成，反复"确认" |
| 模糊报错 | 只返回 500 / timeout，模型原样重试同参数 |
| 缺失败语义 | 没有"放弃"这个动作，只能一直试 |
| 自我怀疑 | 自评"还不够好"→ 重写 → 再自评，标准模糊 |
| 多 Agent 互等 | A 等 B 的输出，B 等 A 的确认 |
| 检索同质化 | 每次都召回同一批文档，换词不换结果 |
success / empty / error / partial，且 error 必须带「建议下一步」。模型有了明确语义，就不会瞎试。| 维度 | 设计 | 评价 |
|---|---|---|
| 感知 | 文件树、diff、命令输出、错误栈 | ✅ 信息闭环完整 |
| 行动 | 开放式（任意命令） | ✅ 能力强 |
| 策略 | 自己验证（跑测试） | ⚠️ 依赖模型自评，缺外部基准 |
不合理处：①没有「变更预览」——改 10 个文件前看不到影响面；②长任务没有里程碑，失败后要重头再来；③成本不可见，跑飞了才知道贵。
我会改进 3 点：①每次批量改动先出 diff 预览 + 一键回滚；②把长任务切成可验收小步（每步有测试）；③界面上常驻显示「已花 token / 剩余预算」。
| 环节 | 用什么 | 理由 |
|---|---|---|
| 身份核验 / 查询 / 出票 / 退款 | 工作流（状态机） | 步骤固定、必须留痕、错一步赔钱 |
| 多程组合 / 改签冲突 / 退票规则判定 | Agent | 规则组合爆炸，需要判断 |
| 用户模糊诉求（"帮我搞个便宜的"） | Agent 先澄清，再回工作流 | 需要理解，但执行必须回轨道 |
混合架构（推荐）：外层状态机管「当前处于哪一步 + 允许哪些动作」；节点内部允许 Agent 自由推理，但输出必须回填到结构化槽位（舱位、日期、乘客、金额）；槽位不全就回到工作流追问。
判据：规则能枚举 → 工作流；需要判断且信息不全 → Agent。
| 场景 | 为什么受限更好 |
|---|---|
| 高风险 / 强合规（空管、医疗、支付） | 每个动作可审计、可回滚、责任可界定 |
| 延迟敏感（实时调度、语音助手） | 从预定义选项里选，一步到位，不"想" |
| 需要评测与回归 | 动作空间固定才能做基线对比 |
| 用户是新手 | 限制选项 = 防误操作 |
反例（受限会拖累）：探索型任务、创意生成、排查未知故障——这些需要"走没人走过的路"。
| 机制 | 作用 |
|---|---|
| 代理授权书 | 预先约定：可做哪些动作、额度多少、有效期多久、谁可撤销 |
| 超时策略显式化 | 超时 = 放弃并回滚，绝不"默认继续" |
| 澄清次数上限 | 最多问一次；第二次仍模糊 → 按最保守方案执行 + 告知 |
| 工程手段 | 为什么会过时 |
|---|---|
| 长 ReAct 模板 + 少样本 | 模型自带规划与工具调用，模板反而约束格式、增加 token |
| 为绕开上下文窗口做的复杂分块召回 | 长上下文普及后，多数场景不需要精雕分块 |
| 规则式工具路由（if/else 派发） | 模型 tool-use 变强后，路由可交给模型 |
| 为稳定性做的极端降级（只允许一次调用） | 能力提升后，过度保守等于自废武功 |
不会过时的原则（对照）：目标可验证、失败可恢复、边界可控、成本可测、行为可审计。手段会换季，原则不会。