用框架写

为什么要从手写循环走到框架？

手写循环适合把 Thought、Action、Observation 走通一次。工具一多、角色一多、还要分支和人工介入，消息格式、停止条件和状态就会在每个脚本里各写一遍。

框架接管的是这些重复部分：消息、模型适配、工具注册、多角色如何交接、流程能不能回到上一步。它不接管你的任务定义和评估。换框架解决不了目标没写清。

常见框架各是什么形状？

按形状记，不要按功能清单记。

形状	代表	状态主要在哪	适合问它的题
多角色对话	AutoGen	对话消息和群聊规则	几个角色轮流说话就能推进的任务
消息驱动的多智能体	AgentScope	显式消息	要工程化管理多个参与者和消息流
角色扮演协作	CAMEL	两个角色的对话协议	用固定角色把任务聊完，而不是用图约束步骤
状态图	LangGraph	图的状态和边上的条件	循环、分支、回溯、人工介入必须显式存在

LangGraph 面试常要补一句：节点是一步计算，条件边决定下一步去哪，状态是这份图共享的数据。它把控制流从提示词里拿出来，放进程序。

选型时先看什么？

1. 控制流要不要显式。要回退和人工确认，优先图，而不是群聊。
2. 角色是真的需要不同上下文，还是一个模型加不同提示就够。
3. 状态、轨迹和工具能不能拿到你自己的存储里做评估。
4. 团队能不能维护这个抽象。框架的对象越多，排错越要懂它的消息生命周期。

答完补一句限制：框架演示很容易跑通，生产成本出在失败分支、权限和观测。选型看失败时长什么样，不看 happy path 的示例。