一周热榜

我们在构建生产环境代理工作流时遇到了特定的故障模式。来自合约的字段导致订阅更新不准确——日期相差一天。产品在应该更新时却被随机创建。税额没有写入税额字段，而是被实例化为全新的产品。每一次失败都像是技术上成功但操作上错误的写入。 HITL（人机协同）有所帮助——一次处理一份合约，并在每一步都进行用户确认，从而保证了准确性。但用户最终表示：“我已经解释了 30 次了，赶紧把它做完。” 当我们减少确认步骤以使其运行起来时，它又开始失败了。 没有错误。没有警报。只有在几周后的对账中才显现出来的偏差。 提示和映射表在边缘上有所补偿，但从未奏效。代理程序没有关于字段在系统之间如何关联的已验证的真实依据——它每次都在推断。而且大多数时候推断得不一致。求助？

对话似乎总是围绕着寻找联合创始人或融资展开。这其实只是表层问题，本质上是结果。作为创始人，是什么阻碍了你？如果能深入挖掘，而不是停留在表面，那就太好了。

一个简化构建 RAG 系统时 LLM 调用、数据库检索、重新排序、对话存储和嵌入的 Python 小型库。 该库有意仅公开跨提供商通用的功能，以避免特定于提供商的参数。 像 LangChain 这样的库提供了许多集成，但通常依赖于许多抽象、大量使用关键字参数以及难以定制的复杂代码。 功能： - 同步和异步 API - LLM 调用：调用和流式传输（温度，推理级别） - 响应元数据：答案、token 使用情况、停止原因 - RAG 文档：检索、重新排序、嵌入 - 聊天历史：对话存储 - 跨提供商的通用错误处理 - 提供商：OpenAI、Anthropic、Google、AWS 重试逻辑留给用户处理（参见 README）。 暂不支持 Agent 功能。

我厌倦了我的 AI 智能体因为 LLM 幻觉 JSON 键或传递字符串而不是整数而崩溃。所以我构建了 ToolGuard——它使用边缘情况（空值、缺失字段、类型不匹配、10MB 负载）对你的 Python 工具函数进行模糊测试，并给你一个 100 分的可靠性评分。<p>运行测试不需要 LLM。它读取你的类型提示，生成一个 Pydantic 模式，并确定性地破坏事物。<p>pip install py-toolguard<p>GitHub: <a href="https:&#x2F;&#x2F;github.com&#x2F;Harshit-J004&#x2F;toolguard" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;Harshit-J004&#x2F;toolguard</a><p>如果你正在构建复杂的工具链，如果你查看该仓库，我将感到非常荣幸。 强烈欢迎对架构进行严厉的反馈！