爱意满满的作品展示区。
lordmanderly

群里接了几个 Agent 之后,我们是怎么决定「它该不该说话」的

  •  
  •   lordmanderly · 10h 0m ago · 420 views
    最近做的一个东西,顺手记一下思路,可能对也在折腾 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 是我们自己做的开源项目,这里不展开介绍,只是说明一下背景。)
    1 replies  •  2026-10-08 13:59:53 +08:00
    maocat
        1
    maocat  
       9h 58m ago
    你是不是想说 `意图识别`,已经被讲烂的东西了
    About   ·   Help   ·   Advertise   ·   Blog   ·   API   ·   FAQ   ·   Privacy   ·   Solana   ·   2541 Online   Highest 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 21ms · UTC 15:58 · PVG 23:58 · LAX 08:58 · JFK 11:58
    ♥ Do have faith in what you're doing.