返回首页
最新
我为智能眼镜开发了一款免提的抬头显示器（HUD），能够运行现实世界的速通计时器，并根据摄像头所见自动进行分段。演示场景：制作寿司。<p>演示视频：<a href="https://www.youtube.com/watch?v=NuOVlyr-e1w" rel="nofollow">https://www.youtube.com/watch?v=NuOVlyr-e1w</a><p>代码库：<a href="https://github.com/RealComputer/GlassKit" rel="nofollow">https://github.com/RealComputer/GlassKit</a><p>我最初尝试使用多模态大语言模型进行场景理解，但由于延迟和一致性不够理想，因此我转向了一个小型物体检测模型（微调的RF-DETR）。该模型仅在摄像头视频流上运行推理循环。这也使得设备本地/离线使用成为可能（目前仍通过本地服务器运行）。
嗨，HN，
我们花了一年时间构建AI代理，但一直遇到同样的问题：提示工程（prompt engineering）并不像软件工程那样。它更像是在猜测。
我们创建了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="Research quantum computing")
def _example_flow(self):
# LLM生成此执行计划。
# 关键是：LLM管理'docs'变量符号，
# 但在规划过程中从未看到其内部的庞大负载。
docs = self.retrieve_documents("当前量子计算的状态")
return self.synthesize_answer(docs)
```
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)
嗨，HN，
在Imbue，我们一直在关注代理领域的快速发展，并注意到代理与第三方服务在用户授权下的互动方式常常不尽如人意。现有的集成方式往往是临时的、复杂的、依赖上下文的，并且要么对非技术用户不友好，要么与某种锁定机制绑定。
我们正在尝试一种命令行工具——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)