最新

我为智能眼镜开发了一个免手持抬头显示器（HUD），它运行一个真实的速通计时器，并根据摄像头所看到的内容自动分段。演示场景：制作寿司。<p>演示：<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=NuOVlyr-e1w" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=NuOVlyr-e1w</a><p>代码库：<a href="https:&#x2F;&#x2F;github.com&#x2F;RealComputer&#x2F;GlassKit" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;RealComputer&#x2F;GlassKit</a><p>我最初尝试使用多模态大语言模型（LLM）进行场景理解，但延迟和一致性对于这个用例来说不够好，所以我切换到一个小型目标检测模型（微调的 RF-DETR）。它只是在摄像头画面上运行一个推理循环。这也使得设备端/离线使用成为可能（目前它仍然通过本地服务器运行）。

Hi HN， 过去一年，我们一直在构建 AI 智能体，但一直遇到同样的瓶颈：提示工程感觉不像软件工程，更像是在瞎猜。 我们构建了 OpenSymbolicAI，旨在将智能体开发转变为真正的编程。它是一个开源框架（MIT 许可证），允许您使用类型化的原语、显式分解和单元测试来构建智能体。 主要问题：上下文窗口滥用 大多数智能体框架（如 ReAct）迫使您将工具输出转储回 LLM 的上下文窗口，以决定下一步。 智能体搜索数据库。 智能体取回 50kb 的 JSON。 您将这 50kb 粘贴回提示中，只是为了问“我下一步该怎么做？” 这很慢，成本高昂，并且会混淆模型。 解决方案：将数据作为变量 在 OpenSymbolicAI 中，LLM 生成一个操作变量的计划（代码）。实际的重型数据（搜索结果、PDF 内容、API 有效载荷）存储在 Python/运行时变量中，并且在特定原语实际需要读取它之前，永远不会通过 LLM 上下文。 可以将其视为智能体的传引用。LLM 操作变量句柄（文档），而 Python 运行时存储实际数据。 示例：RAG 智能体 LLM 不再基于一堆文本幻构一个计划，而是简单地编写操作数据容器的逻辑。 ```python class ResearchAgent(PlanExecute): @primitive def retrieve_documents(self, query: str) -> list[Document]: """从向量数据库中提取大型文档。""" # 返回保留在 Python 内存中的大型对象 return vector_store.search(query) @primitive def synthesize_answer(self, docs: list[Document]) -> str: """使用文档生成答案。""" # 这是唯一实际读取文档文本的步骤 context = "\n".join([d.text for d in docs]) return llm.generate(context) @decomposition(intent="研究量子计算") def _example_flow(self): # LLM 生成此执行计划。 # 关键是：LLM 管理 'docs' 变量符号， # 但在规划期间从未看到其中的大量有效载荷。 docs = self.retrieve_documents("量子计算的现状") return self.synthesize_answer(docs) ``` ```python agent = ResearchAgent() agent.run("研究固态电池的最新进展") ``` 讨论 我们很乐意听取社区的意见： 您在提示工程的脆弱性方面遇到过哪些困难？ 什么会说服您尝试将提示视为代码？ 这种方法在其他领域是否会大放异彩？ 为了让它为您的用例做好生产准备，还缺少什么？ 代码是有意使用简单的 Python，没有魔法，没有框架锁定。如果这种方法引起共鸣，很容易适应您的特定需求或与现有代码库集成。 代码库： 核心（Python）：[https://github.com/OpenSymbolicAI/core-py](https://github.com/OpenSymbolicAI/core-py) 文档：[https://www.opensymbolic.ai/](https://www.opensymbolic.ai/) 博客（技术深度探讨）：[https://www.opensymbolic.ai/blog](https://www.opensymbolic.ai/blog)

Hi HN， 在 Imbue，我们一直在关注代理领域（agent landscape）的快速发展，并注意到代理代表用户与第三方服务交互的方式往往不尽如人意。集成是临时的、复杂的、依赖上下文的，而且要么对非技术用户不友好，要么与某种形式的锁定有关。 我们正在试验一个命令行工具 Latchkey，它可以被面向非技术用户的本地代理使用，同时避免远程中介。据我们所知，这是在实现这两个目标交叉点上唯一现有的方法。 核心理念：代理通过在普通的 `curl` 调用前加上 `latchkey` 命令来访问第三方服务的 API，例如： ``` latchkey curl -X POST 'https://slack.com/api/conversations.create' \ -H 'Content-Type: application/json' \ -d '{"name":"something-urgent"}' ``` 然后，Latchkey 会透明地将凭据注入到这些调用中，并在需要时提示用户通过浏览器弹出窗口登录。浏览器自动化用于从登录后的浏览器会话中提取 API 令牌。 优点： * 一个技能即可与所有服务集成。 * 代理和第三方服务之间的直接通信（不需要 OAuth 中介应用程序）。 * 非技术用户可以使用代理。 * 密钥不会泄漏到日志或聊天记录中。 我们相信这与去中心化未来的愿景相符，在这种未来中，人们不需要向公司请求许可来使用他们自己的数据。我们设想一个充满活力的本地代理生态系统，人们可以自由使用，并由一个社区支持，互相帮助保持这些工具的实用性和功能性。 我们也意识到这种方法也有一些缺点，并希望得到您的反馈。 附注：这里还有一个链接，指向使用 Latchkey 构建的玩具演示 AI 助手应用程序 Passepartout：[https://github.com/imbue-ai/passepartout](https://github.com/imbue-ai/passepartout)