最新

大家好，我们是Alex和Tyler，Voker.ai的联合创始人（<a href="https://voker.ai">https://voker.ai</a>），这是一个为人工智能产品团队提供代理分析的平台。Voker能够全面了解用户对代理的需求，以及代理是否满足这些需求，而无需深入查看日志。我们的主要产品是一个轻量级的SDK，具有与大型语言模型（LLM）堆栈无关的特性，专为代理产品而设计。（<a href="https://app.voker.ai/docs">https://app.voker.ai/docs</a>） 代理工程师和人工智能产品团队在生产环境中对代理性能的可见性不足，这导致了糟糕的用户体验、用户流失，以及数百小时的时间浪费在通过抽查来发现和调试代理配置问题上。 演示：<a href="https://www.tella.tv/video/vid_cmoukcsk1000i07jgb4j65u67/view" rel="nofollow">https://www.tella.tv/video/vid_cmoukcsk1000i07jgb4j65u67/view</a> 我们最近对YC创始人进行了调查，超过90%的受访者表示，他们知道代理在生产中是否未能满足用户需求的唯一方式是听到客户的投诉。他们会推送提示更改，希望能解决问题，而不破坏其他地方的功能，结果这一循环不断重复。 我们看到许多可观察性和评估产品涌现出来，试图解决这些问题，但我们仍然觉得代理监控堆栈中缺少一些东西。可观察性工具适合单个追踪调试，但仅对工程师可用。评估工具适合测试已知问题，但无法提供团队未预料到的趋势洞察，因此工程师总是处于追赶状态。传统的产品分析工具在跟踪产品表面上的点击和页面浏览方面表现良好，但并不是专门为代理产品构建的。了解用户希望从代理中获得什么，以及代理是否满足这些需求，需采用特定的对话智能和非结构化数据处理技术。 我们提出了意图、修正和解决方案的代理分析原语，以描述几乎所有对话代理的共同点：用户总是带着意图来与代理互动，用户可能需要在实现其意图的过程中纠正代理，希望每个用户的意图最终都能被代理解决。 Voker通过自动注释单个对话并提取用户意图和修正来处理LLM调用。Voker利用这些信息，结合LLM和层次文本分类，创建动态类别，提供更高层次的洞察，这样您就不必逐个阅读对话即可了解用户的主要使用模式。 我们看到的最常见替代解决方案是将观察日志上传到Claude或ChatGPT，并请求总结洞察。这存在一些问题——主要是LLM在数学或数据科学方面表现不佳，因此您无法获得准确或一致的统计数据。LLM很可能会对某些洞察过拟合，而对其他洞察欠拟合。LLM并不是以编程方式读取和分类每个单独的会话或交互。这就是为什么我们不使用LLM进行任何核心数据工程（处理事件、计算统计数据），以确保我们生成的分析是一致、可重复和准确的。 我们提供一个公开可用的轻量级SDK，封装了对OpenAI、Anthropic和Gemini的LLM调用，支持Python和Typescript。Voker负责数据工程，将原始数据转化为可用的分析原语和更高层次的洞察。 免费套餐：每月2000个事件，需注册邮箱。付费计划起价为每月80美元，提供30天免费试用。 我们希望了解您目前是如何检测趋势的，如果您尝试Voker，请告诉我们我们分析的哪些部分对您有价值，以及哪些部分仍然感觉缺失。感谢您的阅读，我们期待您在评论中的反馈！

目前，代理式问题解决方案非常脆弱。我对它产生了浓厚的兴趣，但它所带来的问题与解决的问题一样多。 我叫本·科克伦（Ben Cochran），在全栈工程、DevOps、高性能计算和机器学习领域有超过20年的经验，曾在NVIDIA、AMD及其他多个组织工作，最近担任杰出工程师。 为了让代理可靠地工作，你要么需要大量的参数，要么需要巨大的上下文窗口，以保持解决方案空间的可用性。大多数人通过更大的模型和更长的提示来强行提高可靠性。 如果我通过缩小问题而不是扩大模型呢？ 我采取了不同的方法，使用较小的模型：参数范围在130亿到200亿之间，并将其用于解决真实的软件工程基准问题。我通过使用形式状态机来限制工具和解决方案空间。状态机中的每个状态定义了模型可以访问的工具、可进行的迭代次数以及有效的转换。规划状态只能使用只读工具。实现状态可以使用编辑工具（范围限制以防止大规模编辑）和友好的写入bash工具。测试状态可以使用bash，但仅限于测试命令。模型不能在物理上跳过步骤或在错误的时间使用错误的工具。这是通过协议强制执行的，而不是通过提示。 结果比我预期的更有希望。在多个模型系列中，无论其年龄如何（如qwen-coder、gpt-oss、gemma4），在130亿参数的拐点以上，改进都是一致的。在此拐点以下，模型可以导航状态机，但无法保留足够的上下文以产生准确的编辑。有关研究的更多信息，请访问：<a href="https://statewright.ai/research" rel="nofollow">https://statewright.ai/research</a> 令人惊讶的是，这也在前沿模型中带来了改进。Haiku和Sonnet开始表现得超出预期，而Opus在使用更少的令牌和避免死循环的情况下解决问题的可靠性更高。微调并没有为我带来这样的功能性改进。看起来，关键在于上下文窗口的利用比原始上下文的大小更为重要——在每一步中，紧密范围的工作上下文优于对所有内容拥有完全自由的模型。通过使用确定性代码来约束非幂等的LLM是一种目前没人讨论的模式。 因此，我构建了Statewright。它的核心是一个Rust引擎，用于评估状态机定义：状态、转换、保护和工具限制。它的调度不使用LLM，只是强制执行状态机。在此之上是一个插件层，通过MCP与Claude Code（以及即将推出的Codex、Cursor等）集成。当你激活工作流时，钩子会自动根据每个状态强制执行保护措施。模型可用的工具只有5个，而不是数十个，并且在当前阶段获得明确的指令，并在条件满足时进行转换。重要的是，它会告诉模型何时尝试做一些超出范围、错误的事情，或者在卡住后需要尝试其他方法。 你可以通过MCP使用你的代理为你构建一个状态机，以在当前上下文中解决问题。statewright.ai上的可视化编辑器让你可以在图形视图中调整这些工作流……你可以清楚地看到失败路径、重试循环和审批门。状态机不是有向无环图（DAG）；它们会循环和重试，这正是代理工作所需的。 Statewright目前已经上线，提供免费层级，可以通过在Claude Code中运行以下命令进行尝试： ``` /plugin marketplace add statewright/statewright /plugin install statewright /reload-plugins ``` 然后“启动bug修复工作流”或`/statewright start bugfix`。当提示时，你需要粘贴你的API密钥。最新版本的Claude可能会发出警告——再次粘贴API密钥并说明你是认真的，Claude只是小心而已。 欢迎对工作流编辑器、插件体验提供反馈，并告诉我你希望首先构建哪些工作流。代理是建议，状态是规则。

嘿，HN，我是Sina。 我有一些Cloudflare的积分将在5月14日到期，不知道该如何处理。当Kimi K2.6发布并在Workers AI上可用时，我决定用它构建一个开源的Claude代码克隆。对此我没有多想。（有人问我是否知道OpenCode，老实说，我是在构建这个之后才了解到它们的，但它们看起来真的很棒。） 总之，Kimiflare是一个CLI编码助手，基本上是Claude代码，但由Kimi K2.6在Cloudflare Workers AI上提供支持。 目前版本是v0.57.0，已经获得了超过12,000次的npm下载，137个GitHub星标，以及来自4位贡献者的PR（包括Marshall Thompson在FeatherJS中的Zed/ACP集成）。积分是Cloud层存在的唯一原因，因此一旦它们在周四到期，我将停止该服务，项目将继续作为开源/自带密钥（BYOK）进行。 我将向在积分到期之前注册的每位用户赠送500万代币——无需信用卡。您在注册时选择Cloud选项时，将自动获得这些代币。 代码库： [https://github.com/sinameraji/kimiflare](https://github.com/sinameraji/kimiflare) 安装：npm i -g kimiflare 欢迎随时提问。 附言：我在Kimiflare的前2-3次提交中使用了Claude代码，然后从v0.3.0开始使用Kimiflare自我构建，以实现最大程度的自我使用。这是一次有趣的经历。