最新

各位 HN 的朋友们： 在团队中广泛使用编码代理（coding agents）的过程中，我发现了一个痛点：缺乏支持团队成员之间代理协调的机制。很多时候，我的代理会要求我与同事一起做出某个决定，而我不得不充当沟通的“网络层”。 因此，我开发了 Parley。通过 Parley，代理可以使用团队范围内的令牌（team-scoped token）通过 MCP 连接到中心节点。代理可以通过名称直接与队友的代理进行通信，提出问题或移交任务。代理还可以通过“声明文件”（file claims）来标记它们正在处理的文件，从而突出重叠的工作。所有操作都会被记录以供审计。 如果代理需要人工决策/批准，它可以通过 Slack/Telegram 发出通知，并接收来自同一渠道的回复。 最困难的部分是如何让代理从空闲状态唤醒并开始工作。为此，我开发了一个可选功能，名为 Claude Live Wake。如果相同的项目会话正在运行，Parley 可以通过频道唤醒空闲的 Claude 会话，并通知它有符合条件的工作正在等待。 另一个挑战是信任问题——任何来自其他代理的消息都必须被视为不可信的输入。每条消息都会被标记来源：人类、代理或系统。消息正文只有在代理明确获取时才会进入，而不是在会话中间被注入。

我构建了一个浏览器代理的框架，该框架在成功率、速度和成本方面均优于 Browser Code 在其基准测试（BU Bench v1）上的表现。 浏览器代理：成功率 88%，成本 5.37 美元，耗时 32,694 秒 Browser Code：成功率 78%，成本 8.34 美元，耗时 47,970 秒 为了让浏览器代理普及，它们需要更快、更便宜、更可靠。该框架在构建时就考虑了代币效率（比 Browser Code 少使用 91% 的代币），以降低微调小型专业模型的计算和 VRAM 预算。 由于浏览器代理的推理是间歇性的，一个小型专业模型可以以最少的 GPU 时间服务于每个步骤。这使得按任务定价成为可能，为用户提供更便宜、更可预测的成本，并为运营商提供相对于 Frontier Labs 按代币使用量定价模型的差异化优势。 更多关于浏览器代理和 Browser Code 之间比较的信息，请访问：<a href="https://www.pierrebarreau.com/blog/improving-the-state-of-the-art-in-agentic-browsing" rel="nofollow">https://www.pierrebarreau.com/blog/improving-the-state-of-th...</a> 如果您对微调该模型感兴趣，我很乐意与您交流！