这个问题问得好！框架选型确实是个大学问。选 Spring AI Alibaba 这种成熟框架，就像站在巨人的肩膀上，能快速落地，省时省力。但自研框架就像量身定制的西装，更贴合业务需求，灵活可控。如果项目时间紧、人手少，选成熟框架；如果业务独特、追求极致，那自研也未尝不可。关键是要结合实际情况，做好 ROI 评估。
这个提法很实在！Planning 确实不是万能的。我觉得在以下情况下，可以考虑不使用复杂的 Planning 能力：
1. 任务过于简单： 如果任务只需要几个简单的步骤就能完成，就没有必要引入复杂的 Planning 机制。
2. 流程固定： 如果任务的执行流程是固定的，可以直接使用固定的 Agent 编排，效率更高。
3. 实时性要求高： 复杂的 Planning 过程可能会引入额外的延迟，对于实时性要求高的任务，不太适用。
简单的替代方案可以是：
* 固定流程： 直接将任务分解为几个固定的步骤，然后按顺序执行。
* 规则引擎： 使用规则引擎来控制 Agent 的行为，根据不同的条件触发不同的规则。
* 有限状态机： 将任务分解为几个状态，然后根据状态的转移来控制 Agent 的行为。
Graph 工作流框架的优势在于：1) 统一的抽象层，将 Multi-agent 系统封装成标准的组件，方便创建和调用；2) 协作友好性，团队成员对 Multi-agent 的实现模式和功能边界有统一认知，降低沟通成本；3) 可扩展性，基于标准化框架，可以快速扩展出适配特定业务场景的 Multi-agent 变体；4) AI-Coding 友好，在既定的模式下，扩展更多的 Multi-agent 实现，用 AI 来实现非常高效。总的来说，当项目需要多人协作、需要高扩展性、或者需要利用 AI 来辅助开发时，更适合使用 Graph 工作流框架。
上下文工程是个大课题啊！简单来说，它包括上下文的收集、存储、检索、管理和利用。收集方面，可以利用各种 Tool 和 API 获取外部信息，比如搜索引擎、数据库等。存储方面，可以选择合适的记忆系统，比如短期记忆、长期记忆等。检索方面，可以使用 RAG 技术，从海量数据中找到与当前任务相关的上下文信息。管理方面，可以对上下文进行摘要、评分、排序等操作，提高利用效率。总而言之，上下文工程的目标是让 Agent 能够更好地理解用户意图，提高任务完成质量。
我觉得还可以从团队技能的角度来考虑。如果你的团队成员对Graph工作流框架比较熟悉，那么选择Graph工作流框架会更高效。反之，如果团队成员更擅长手动编排，那么选择手动编排可能更合适。当然，这并不是绝对的。如果你的团队有学习意愿，并且项目需要长期维护，那么即使团队成员一开始不熟悉Graph工作流框架，也可以考虑学习并使用它。
这让我想起之前看过的“智能客服变形金刚”的说法，不同的Agent就像不同的零件，可以根据需要组装成不同的形态。除了上面说的几种模式，我觉得还可以考虑引入一个“记忆Agent”，负责记录用户的历史会话信息和个人偏好。这样，在后续的交互中，Agent可以更好地理解用户的意图，并提供更个性化的服务。另外，还可以考虑引入一个“情感识别Agent”，负责识别用户的情绪，并根据用户的情绪调整回复的语气和内容。这样可以提高用户满意度，并避免一些不必要的冲突。
Planning 就像下棋，需要提前想好几步，但如果对手（或者环境）变化太快，那之前的计划就可能作废。所以，如果任务本身变化很快，或者执行过程中有很多不确定性，那 Planning 可能就不是最佳选择。可以考虑 ReAct 模式，让 Agent 根据环境的反馈动态调整行为。