GitHub Trending 经常会把新的 agent 框架推到开发者视野里。agency 这类项目的吸引力很直接：少量代码定义多个 agent，让它们互相发消息、调用工具、协作完成任务。相比大型工作流平台，轻量框架更像一个可插拔的实验台。
但 agent 框架的评估不能只看 README demo。Demo 里多 agent 对话很顺畅，到了生产环境就会遇到完全不同的问题：状态怎么保存，工具怎么限权，失败怎么恢复，日志怎么检索，成本怎么归因，用户怎么中断任务。
本文用工具速评的方式看 agency 类框架：它们适合做什么，不适合做什么，团队试用时应该检查哪些点。
轻量框架的价值
轻量 agent 框架最大的优点，是让你很快验证分工是否有价值。
例如一个代码审查任务，可以拆成：
- Reader：读取 diff 和上下文。
- Security reviewer：关注注入、越权和数据泄露。
- Test reviewer：关注测试缺口。
- Summarizer：合并结果并排序。
如果用纯手写代码，你要先设计消息结构、调度循环和角色边界。用轻量框架，通常几十行就能跑起来。这对研究、内部工具和原型非常有用。
轻量框架的第二个价值，是降低团队理解成本。大型 agent 平台往往引入 graph、state machine、memory、planner、executor、runtime、deployment 等许多概念。轻量框架如果只抽象 agent、message、tool，开发者更容易看懂。
第三个价值，是方便替换模型。很多框架不会强绑定某个供应商，而是把模型调用作为 adapter。对于今天模型快速迭代的环境，这一点很重要。
多 agent 的真实成本
多 agent 的问题也很明显。每多一个 agent，就多一段 prompt、多一次模型调用、多一份状态和多一个失败点。
常见成本包括：
- 延迟上升：多个角色串行讨论会显著增加等待时间。
- token 成本上升：每个 agent 都要读取任务上下文。
- 责任分散：输出错误时很难定位是哪个 agent 的判断导致。
- 幻觉扩散：一个 agent 的错误假设可能被另一个 agent 当作事实引用。
- 调试困难：最终答案只是最后一轮文本，真实决策链藏在中间消息里。
所以，多 agent 不是默认升级路线。很多任务用一个模型加几个工具就够了。只有当任务需要审查、制衡、并行探索或专业分工时，多 agent 才有明显价值。
试用 agency 类框架的六个问题
第一，状态模型是否清楚？
框架应该能回答：一次任务运行的状态在哪里，消息历史如何裁剪，工具结果如何保存，失败后能否恢复。如果状态只存在内存里，框架更适合 demo，不适合长任务。
第二，工具调用是否强类型？
工具参数必须有 schema。模型输出不能直接进入文件系统、数据库、shell 或外部 API。一个框架如果只提供自然语言工具描述，没有运行时校验，就要自己补。
第三，权限是否能按 agent 分配？
安全 reviewer 不需要写数据库，summarizer 不需要调用部署工具。不同 agent 应该拥有不同工具集。否则多 agent 只是多个 prompt 共享同一把万能钥匙。
第四，日志是否可检索？
至少要记录 task id、agent name、model、prompt hash、tool call、latency、token usage、error。没有结构化日志，多 agent 的问题很难排查。
第五，是否支持中断和恢复？
生产任务可能被用户取消、超时或部署重启。框架需要让调度循环能停下来，并把已完成状态保存。
第六，测试是否容易写？
你应该能 mock 模型输出，固定工具返回，跑一次确定性的 agent 流程测试。如果每次测试都必须真实调用模型，回归会又慢又贵。
一个最小评测任务
试用新 agent 框架时，不要从复杂业务开始。可以用一个固定任务评测：
输入：一个 pull request diff 和相关文件片段
目标：找出最多 5 个高风险问题
约束：必须给文件路径、行号、风险原因和建议测试
角色：reader、security reviewer、test reviewer、summarizer这个任务有几个好处。它足够真实，能测试上下文传递、角色分工和结构化输出；同时不需要写入外部系统，风险低。你可以准备 10 个带已知缺陷的 diff，比较不同框架的成功率、成本和延迟。
评测指标应包括：
- 是否找到真实缺陷。
- 是否产生误报。
- 是否引用不存在的行号。
- 平均模型调用次数。
- 平均延迟。
- trace 是否足够定位错误。
如果一个框架在这个小任务上都难以调试，进入更复杂的生产场景只会更痛苦。
与 LangGraph、CrewAI、AutoGen 的关系
agency 类轻量框架通常和 LangGraph、CrewAI、AutoGen 不在同一个复杂度区间。
LangGraph 更偏显式状态机和可控流程，适合需要确定路径、恢复和复杂状态管理的系统。
CrewAI 更强调角色协作和任务编排，适合业务人员也能理解的多角色流程。
AutoGen 更偏研究和对话式多 agent 实验，适合探索 agent 间交互模式。
轻量 agency 框架的优势是上手快、概念少、容易改。缺点是生产基础设施往往要自己补。选型时不要问“哪个框架最强”，而要问“我的任务需要多少控制力”。
什么时候值得采用
适合采用的场景：
- 内部自动化原型。
- 多角色审查实验。
- 研究 demo。
- 教学项目。
- 单机运行的开发者工具。
- 低风险批处理任务。
谨慎采用的场景：
- 涉及付款、删除、发布等高风险动作。
- 长时间运行的后台任务。
- 多租户 SaaS。
- 需要严格审计的企业工作流。
- 需要高并发和稳定 SLA 的平台服务。
在谨慎场景里，你仍然可以用框架验证思路，但生产实现应把关键编排逻辑掌握在自己手里。
框架之外必须自建的部分
无论 agency 框架多轻巧，生产团队通常都要自建这些东西：
- 模型网关：路由、降级、重试、成本统计。
- 工具注册表：schema、权限、幂等和审计。
- 任务数据库：状态、消息、artifact 和错误。
- 评测集：固定输入、期望输出和失败样本。
- 监控面板：成功率、延迟、成本和人工介入率。
- 权限系统：按用户、租户、agent 和工具授权。
框架可以帮你表达 agent 协作，但不能替你承担平台责任。
结论
agency 类框架适合快速验证多 agent 分工是否真的有收益。它的轻量是优点，尤其适合原型和内部工具。但轻量不等于生产完备。真正上线前，你必须检查状态、权限、工具 schema、日志、恢复和测试。
我的建议是：用它做实验，用自己的评测集判断多 agent 是否提升结果质量；如果有效，再把关键模式迁移到更可控的编排层。不要因为 demo 漂亮就把生产权限交给框架，也不要因为框架简单就忽略它在原型阶段的价值。