· ARJUN · WRITING
选 Agent 框架之前，先把任务流程画出来
工单助手查完文档，还可能需要追问、等待用户回复，再接着处理。沿着这条流程筛选 Agent 框架，再用同一批任务比较结果、延迟和成本。
假设要给技术支持团队做一个助手。用户发来一张工单：“升级后登录不了了。”
第一个版本可能很简单：检索产品文档，整理几个排查步骤，交给支持人员。很快，需求就会增加：查一下账号状态，确认升级前后的版本；信息不全时先追问；用户几个小时后回复，助手还要接着往下处理。
此时，选型已经涉及会话状态、工具执行和任务恢复。只看某个框架能不能调用模型，很难判断它能否接住后面的开发工作。
先看这张工单怎么处理
把这个假设场景展开，可以得到一条具体的执行过程：
- 从工单中提取已知信息，列出产品、账号和版本中尚未确认的部分。
- 缺少查询所需的信息时提出具体问题，保存进度，等待回复。
- 信息齐全后，调用账号查询工具，检索对应版本的文档。
- 结合返回材料给出有依据的排查建议；仍无法判断时，把已查到的事实和待确认问题交给支持人员。
这条流程里有不同性质的步骤。根据账号 ID 查状态，可以由程序直接执行；从用户描述中判断该检索什么，需要模型参与；等待回复、记录进度和恢复任务，则需要运行时与存储配合。
如果当前需求只涉及一次检索和回答，直接用模型 SDK 加业务代码就可以做基线。需要模型连续选择工具时，再比较现成的 Agent 循环。等到流程有明确分支、跨请求等待或恢复要求时，才有充分理由仔细比较编排与持久化能力。
“支持保存状态”也需要进一步确认：状态存在内存、数据库，还是托管服务中？进程重启后还能不能取回？例如，LangGraph 的 checkpointer 用于保存线程内的图状态，但内存实现不能跨进程重启保留数据，需要配置适合部署环境的存储。具体行为见官方持久化文档。
用需求筛候选，框架名单会短很多
先列清团队使用的语言、部署方式、现有数据接口，以及谁负责维护这套系统。这些条件往往比功能清单更早缩小范围。
LangChain 有 Python 和 JavaScript 实现，不能把它当成“只支持 Python”的框架。Java 团队也可以把其他语言的 Agent 做成独立服务，但需要承担额外的部署、通信和排障工作。是否值得引入这个边界，要看团队已有的系统和维护能力。
下面这些入口可以帮助整理候选，它们的能力有重叠：
| 当前最需要解决的事 | 可以先考察的候选 | POC 中要看什么 |
|---|---|---|
| 给模型接工具，运行标准 Agent 循环 | LangChain | 工具接口、上下文组织和中间件是否适合业务 |
| 显式安排分支、等待与状态流转 | LangGraph | 状态怎样保存，任务怎样暂停和继续 |
| 已有 LlamaIndex 数据与检索组件，想串起处理步骤 | LlamaIndex Workflows | 事件与步骤能否清楚表达现有流程 |
| 以角色和任务组织多个 Agent | CrewAI | Crews 与 Flows 的组合是否便于维护 |
| 在 Spring 应用内接入模型和业务工具 | Spring AI | 能否复用现有服务接口与运维方式 |
| 需要可视化配置和应用管理界面 | Dify | 自定义逻辑、版本管理与部署方式是否合适 |
LangChain 的 Agent 基于 LangGraph 构建。使用标准 Agent 循环和直接编写图，是不同层次的开发选择，不能简单分成“前者只能做 Demo，后者才能上生产”。CrewAI 的 Flows 也支持条件路由和状态持久化，不能只按固定角色流水线理解它。
候选的维护状态同样值得查。核对到 2026 年 10 月 16 日时，AutoGen 官方仓库已标明进入维护模式，并建议新用户从 Microsoft Agent Framework 开始。对于已有 AutoGen 项目，还要单独评估迁移工作。
不必为了覆盖所有名字，把每个框架都实现一遍。挑出与关键需求匹配的一两个候选，再和简单基线比较，通常更容易看清差异。
POC 要跑到会暴露差异的地方
对这个工单助手，只有“查到文档并生成回答”还不足以区分候选方案。可以准备几种情况：信息齐全；缺少版本；查询工具超时；等待用户回复期间进程重启。
观察重点也随之具体起来：重启后还能找到哪张工单、已经查过什么、现在等谁回复？工具失败时，支持人员能否从执行记录中看出停在哪一步？
做对照时，尽量固定模型、Prompt、工具定义、文档快照，以及并发和超时设置。否则，一套实现换了模型，另一套仍用旧模型，结果变化就无法单独归因于框架。如果确实要比较各自调优后的最佳实现，也应该把模型和配置差异一起记录。
同一任务可能出现不同结果。报告需要交代样本数、重复次数和失败情况；单次成功更适合证明路径能跑通，还不能说明长期表现。
先写清“完成”是什么
对“升级后登录失败”这类工单，通常没有唯一标准答案。评估可以先规定必须确认的信息，以及在信息不足时应该采取的行动。
例如，一条用于比较实现的用例可以这样写：
用例：登录失败，但产品版本未知
输入：用户说“升级后登录不了了”
已知条件：账号已确认；产品版本未提供
预期结果：询问版本，并把任务标记为等待用户回复
不应出现：把某一版本专用的修复步骤当成已确认结论这里，提出追问就满足了这条用例的要求。另一条信息齐全的用例，则需要检查建议是否适用、引用是否有效，以及结论是否与账号查询结果一致。
结果标准与执行路径可以分开规定。只要有多条合理路径，就不必要求工具调用顺序完全一致；业务确实要求先查账号再做某项判断时，再检查这个前后关系。执行轨迹适合解释结果和定位问题。
把结果、耗时和成本放在一起看
下面是一套适合这个例子的指标口径。它们是评估设计建议，需要按实际业务调整。
| 指标 | 在工单助手中怎样定义 |
|---|---|
| 任务通过率 | 满足该用例全部验收条件的运行次数 ÷ 全部评估运行次数。超时、异常和未完成也保留在统计中；正确追问是否算通过，由用例预先规定 |
| 工具使用质量 | 分开记录工具选择、参数的业务含义、参数格式和工具执行结果，避免混成一个“调用准确率” |
| 回答的依据与正确性 | 核对结论有没有材料支持，再核对材料是否适用于该产品和版本 |
| 延迟 | 看 P50（中位数）、P95（95 分位数），以及超时和未完成数量。区分首条响应、最终结果和等待用户回复的时间；注明分位数统计是否包含失败运行 |
| 成本 | 记录每次运行成本，并计算全部评估运行总成本 ÷ 通过的运行次数，让失败运行的花费也进入“每次通过成本” |
有依据不等于结论正确。检索到了旧版本文档，助手即使忠实复述，也可能给当前版本提出错误建议。Ragas 的 Faithfulness 衡量回答中的主张是否得到检索上下文支持，不能单独代替业务正确性判断。
成本也不能只拿总 token 数乘一个单价。输入、输出和缓存可能采用不同计费口径，工具与基础设施也可能收费。可以先分别记录，再汇总；评估器自身的费用另外列出。若没有任何运行通过，“每次通过成本”就没有可用的分母，不能报成零。
模型调用次数、工具调用次数和重试次数有助于解释耗时，但步数少并不自动代表效果更好。少查一次账号可能更快，也可能漏掉决定性信息。可观测到的调用事件已经足以支持这类分析，无需把模型生成的思考文字当成可靠的内部推理记录。
评分也要能回到证据上
账号 ID、输出字段、任务状态等可确定的条件，适合用代码检查。建议是否完整、解释是否清楚，可以通过 LLM-as-a-Judge 辅助评估：让模型按明确的评分标准（rubric）判断，并给它相关文档与工具结果。
Judge 的模型更强，并不意味着评分天然可靠。先拿一批人工判断过的案例对照，检查它是否把流畅的错误答案判成通过，再调整标准和示例。关键结论还应保留人工复核。可参考 LangSmith 的评估概念与 Arize 的 Judge 校准实践。
不必一开始就凑几百条用例。先让数据覆盖主要任务和已知失败分支，再逐步补充。用于反复调 Prompt 的案例，与留作最终比较的案例分开保存，才能减少对熟悉样本的偏好。
回到这个助手：如果需求仍然只是检索后整理建议，简单实现就有比较价值；如果它必须等待回复、跨进程继续处理，POC 就应把这段流程跑出来。最终的选型记录需要说明候选版本、运行条件、通过了哪些任务，以及还卡在哪些地方。这样，下一次需求变化时，团队能据此重新判断。