最近做的一个东西，顺手记一下思路，可能对也在折腾 Agent 的人有点用。 背景是这样：我们把几个 coding agent 接进了团队的 Slack 和 GitHub 。接进去之后很快发现一个问题——Agent 不知道什么时候该闭嘴。一个支持频道里，有人提问，有人贴报错，也有人回一句「好的谢谢」。如果每条都回，很快就没人愿意把它留在群里了。 最早的做法是最直觉的那种：把消息丢给大模型，问它「这条需要回复吗」，再解析返回值。能用，但有两个地方一直别扭： - 每条进来的消息都要走一次完整的模型调用，延迟是用户能感觉到的。 - 模型偶尔会很热情地解释它为什么这么判断，而不是老实返回我们要的那个值，于是我们得在返回里做字符串处理。 后来换了个思路：这种判断其实不需要「生成」，只需要「判断」。现在这部分交给 TypeSafe 的 Jev 来做——定义一个问题和判定标准，它返回一个带概率的类型化结果，路由逻辑写在我们自己的代码里，而不是写在 prompt 里。 这个区别比我原本以为的重要。想调「多严才回复」的时候，改的是一个阈值数字，而不是去改 prompt 里的一句话——后者经常会顺带影响到别的三个地方。 目前用在这几处： - 判断一条消息要不要回； - 新对话分流，技术问题给工程 Agent ，账单问题给支持 Agent ； - 新会话启动时选模型。有个我们自己觉得挺好玩的用法：按 PR 作者分配审查者，Claude 写的让 Codex 审，Codex 写的让 Claude 审。 也有不适合用的地方，这部分可能更有参考价值： - 需要把判断理由讲给人听的场景。概率分布不是解释，人被判错的时候想要的是理由。 - 真的需要多步推理的判断。官方文档建议拆成多个原子问题再在代码里组合，这个建议是对的，但有时候老实承认「这里就是需要推理」，直接调大模型更合适。 - 判定标准本身就说不清楚的场景。问题问得很干脆、标准却含糊，比 prompt 还糟，因为它看起来很严谨。 不打算说这个思路有多新。「这不就是分类器套了层好用的接口吗」——这个说法我觉得没错。对我们来说有价值的恰恰是那层接口：不用自己训练、自己部署、自己维护，定义完能先拿样例跑一遍再上线。 写得细一些的版本在这里，有截图： https://www.agentconnect.md/zh/blog/introducing-jev-support/ 仓库： https://github.com/agentconnect-md/agentconnect （利益相关：AgentConnect 是我们自己做的开源项目，这里不展开介绍，只是说明一下背景。）

  • 情报分类：开源项目与落地
  • 分类依据：内容涉及项目实践、创业、副业或变现
  • 信息来源：服务器 / V2EX
  • 发布时间：2026/10/8 13:57:52