先记住这个答案
简单可行方案能减少不必要的决策点、状态同步和运行成本，也更容易定位失败。如果任务输入和步骤稳定，一次模型调用、检索增强或固定工作流可能已经足够。只有评估显示现有方案无法处理动态任务、未知步骤或环境反馈时，才考虑加入更自主的规划与循环。这里的简单以满足目标为前提，不是省略必要校验，也不是禁止使用 Agent。
- 先识别真实失败原因，再选择对应的增强机制
- 稳定流程适合明确编排，动态探索才需要更多自主决策
- 用同一评估集比较收益、成本与新增故障面
先判断问题是不是缺少自主决策
例如把固定格式的工单分成几个已知类别，规则或一次分类调用可能就能完成。若主要错误来自类别定义重叠，增加规划循环未必有帮助。先澄清标签边界并补充评估反例，通常比让模型反复思考分类更直接。
当任务要求在未知代码库中定位缺陷，下一步可能依赖刚读取的文件和测试结果，固定路径更难覆盖。此时动态工具选择和反馈循环有实际价值。是否使用 Agent 应取决于决策的不确定性，而不是界面是否需要呈现一个聊天窗口。
用基线找出应该增加的那一层
可以先跑现有简单方案，按失败原因分组。若回答缺少项目知识，就检查检索；若工具参数经常填错，就改契约和校验；若长任务忘记进度，再考虑状态与摘要。不同问题需要不同机制，不宜一次同时加入规划、记忆和多个执行者后再猜哪项有效。
新增一层后用同样任务重新比较，并检查原本容易的任务是否变慢或退化。记录实际完成结果、调用次数、耗时和恢复行为，不能只凭单次演示更流畅判断改进。保留简洁的回退路径，也有助于发现复杂方案没有提供足够收益时及时调整。
承认简单方案有适用范围
简单固定流程在输入变化很大时可能堆积大量分支，最终反而难维护。此时可以把稳定部分留给代码，将真正不确定的局部交给模型处理，形成混合设计。并非只能在完全固定和完全自主之间二选一。
对复杂度的评估还包括观察和恢复成本。多层调度会产生更多中间状态，失败时需要知道哪一步完成、哪些外部效果已经发生。若团队无法解释一次失败的来源，应先补足记录与契约，再扩大自治范围，否则系统规模越大越难判断是否可靠。
容易答错的地方
- 把简单等同于没有测试和恢复
- 缺少必要保护只是功能不完整，不能算作满足目标的更简单方案。排查“Agent 开发先选择最简单可行方案”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
- 认为多 Agent 一定比单 Agent 强
- 协调、共享状态和结果合并都有代价，是否有收益要看子任务独立性与真实评估。排查“Agent 开发先选择最简单可行方案”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
面试官还会怎么问？
最简单方案的标准是什么？
在满足明确目标和约束的前提下，具有较少非必要组件和决策点，并能通过代表性任务检查。针对“Agent 开发先选择最简单可行方案”，还应保留最小复现、预期结果和失败路径，避免只凭一次现象下结论。
什么时候应停止继续加机制？
当新增机制没有稳定改善目标指标，或收益不足以覆盖成本与故障复杂度时，应保留已有可工作的结构。
如何避免一直停留在简单但能力不足的方案？
持续维护能力缺口和失败样本，明确哪类新任务需要突破当前结构，用证据驱动升级而不是把简单当教条。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。