最新

LLM 代理通常将原始 JSON 工具输出直接放入提示中。经过几次工具调用后，早期的结果会被压缩或截断，导致答案变得不正确或不一致。 我构建了 Sift，一个即插即用的 MCP 网关，它将工具输出存储为本地工件（在 SQLite 中索引的文件系统 blob），并在响应较大或分页时返回一个 `artifact_id` 以及紧凑的模式提示。 模型不是在提示中对完整的 JSON 进行推理，而是运行一个小的 Python 查询： ```python def run(data, schema, params): return max(data, key=lambda x: x["magnitude"])["place"] ``` 查询代码在受限的子进程中运行（AST/导入保护 + 超时/内存限制）。只有计算结果才会被返回给模型。 基准测试（Claude Sonnet 4.6，12 个数据集上的 103 个问题）： - 基线（提示中的原始 JSON）：34/103 (33%)，1070 万个输入 token - Sift（工件 + 代码查询）：102/103 (99%)，48.9 万个输入 token 开放基准测试 + MIT 代码： [https://github.com/lourencomaciel/sift-gateway](https://github.com/lourencomaciel/sift-gateway) 安装： ```bash pipx install sift-gateway sift-gateway init --from claude ``` 适用于 Claude Code、Cursor、Windsurf、Zed 和 VS Code。现有的 MCP 服务器和工具无需更改。

我的 AI 代理即使在提供了规范和文档的情况下，仍然会暴力破解和猜测 API 接口。 即使有完整的 API 规范、一个发现端点和最新的文档，代理仍然会尝试随机格式、猜测参数，并进行不必要的试错。 我能够在客户端对代理进行微调，然后它就能正常工作，直到上下文被清除，但我不希望在 context/agents.md 中硬编码如何访问一个会不断变化的 API。我讨厌所有这些非确定性编程，但它实在太好了，不能不用 :) ----> 问题 总之，问题很简单：API 响应只返回结果，因为它们遵循现有的 REST 协议。 没有结构告诉代理下一步该做什么。因此，我不得不不断地在客户端纠正代理的行为。 每次 API 规范发生变化或代理的上下文被清除时，整个过程就会重新开始。 ----> 解决方案！ 这就是我转向 TEKIR 的原因。 项目仓库： [https://github.com/tangelo-ltd/tekir/](https://github.com/tangelo-ltd/tekir/) ---- TEKIR 通过以下字段扩展了 API 响应： > next_actions（下一步操作） > agent_guidance（代理指导） > reason（原因） 允许 API 明确地告诉 AI 下一步该做什么。 这不仅适用于错误，也适用于成功的响应。 例如，当订单被确认时，API 可以用如下指令指导代理： >>> “向用户显示摘要 跟踪功能尚不可用 取消是不可逆转的，请征求确认” 而不是让代理尝试推断工作流程。 ----> TEKIR 与现有标准配合良好。 TEKIR 的工作方式不会破坏现有的 API。它与 RFC 9457（HTTP API 的问题详情）兼容，并且与语言和框架无关。 有一个 npm 包和 Express/Fastify 中间件可用，但您也可以简单地将 markdown 规范放入您的项目中，并告诉 Claude 或 Cursor 等工具使 API 与 TEKIR 兼容。 ----> 与现有的 RFC 9457（问题详情）和 HATEOAS 的区别 RFC 9457 侧重于问题——它明确描述了错误。TEKIR 更进一步。它是一个关于未来交互的指南，有点类似于 HATEOAS，但具有更好的可读性，并且专门为自动化代理量身定制。 ---> 一些背景资料 为什么叫“Tekir”？ “Tekir”是土耳其语中虎斑猫的意思。 虎斑猫是大自然中最具韧性的设计之一——数千年来混合的基因，街头磨练的本能。它们进化超越了生存；它们适应并在几乎任何环境中茁壮成长。 这也是我想带入这种动态 API 设计中的概念。 ----> 我认为没有人会读到这里，所以我感觉很勇敢。 这个名字也有更个人的一面。 今年一月，我心爱的猫 Çılgın（在土耳其语中是“疯狂”的意思）被车撞了。我无法摆脱这个想法，所以我用它的名字来命名这个项目，这样它的名字就能以某种方式流传下去。 它是一只 tekir 猫。非常独立，非常聪明，老实说比大多数 AI 系统，甚至可能比大多数人类都更“人性化”。 这个项目背后的想法反映了这种精神：无需不断监督就能弄清楚下一步该做什么的系统。 我也意识到这个名字在技术上也能起作用： TEKIR - 智能推理的透明端点知识 ---->> 项目链接 项目页面（EN / DE / TR） [https://tangelo-ltd.github.io/tekir/](https://tangelo-ltd.github.io/tekir/) GitHub [https://github.com/tangelo-ltd/tekir/](https://github.com/tangelo-ltd/tekir/) 我通常不会费尽心思对这类想法大做文章，但最近大量微小想法涌入社区的努力让我充满希望，如果其他构建代理驱动系统的人遇到了同样的 API 交互问题，将会很有趣，也许我只是“用错了”。

玉兔是一个 YouTube 的命令行界面 (CLI)、MCP 服务器和 AI 代理，可自动化您的整个 YouTube 工作流程。

基于 OpenAI 实时 API + Twilio SIP，构建了一个开源语音技能，让 AI 智能体能够进行真实的电话交谈。原生语音到语音，无需 STT-LLM-TTS 链，延迟低于 200 毫秒。功能包括：呼入/呼出电话、通话中工具调用、录音、转录、会话桥接、健康监测、指标、通话记录 API。应用场景：针对预约未接来电的自动回拨（平均每个未接来电损失 2100 美元）。技术栈：Python + Node.js，97 个测试，MIT 许可，5 分钟快速入门。

在大型 Rust 代码库上工作。Token 问题确实存在——Claude Code 乐于花费 5 美元的上下文费用，仅仅为了理解两个模块之间的关系，却一行代码都不写。而且，一旦上下文压缩开始，情况会变得更糟——代理会完全失去思路，并从头开始重新搜索相同的文件。<p>我尝试过的方法：<p>手动输入 CLAUDE.md / 架构文档——有帮助，但很快就会过时。Cursor 的内置索引——在单体仓库上会崩溃，而且我不喜欢将专有代码发送到他们的服务器。基于 grep 的基本 MCP 服务器——适用于精确匹配，对语义查询无用。<p>最终构建了一些更复杂的东西：一个本地 Tree-sitter 索引器，它构建了文件关系的知识图谱，并通过 MCP 暴露出来，这样代理就可以进行语义查询，而不是盲目地使用 grep。一个工具调用代替 15 次 grep 迭代。在这里发布了它：https://github.com/Muvon/octocode<p>但我真的很好奇其他人都在做什么，然后再深入研究它。<p>三个具体问题：<p>1. 你如何处理“涟漪效应”问题——知道更改一个文件会在语义上影响其他文件，即使它们之间没有明显的链接？<p>2. 你信任闭源索引处理专有代码吗，还是选择了本地优先？<p>3. 有人实际大规模地让 GraphRAG 风格的关系映射工作起来了吗，还是它仍然主要是一种炒作？