不一定是最强大的那个。
我更感兴趣的是那些引入了真正有趣的想法或以不同方式解决问题的项目。
可以是开源、研究、基础设施、编排、记忆系统、代理框架,或任何其他与自主系统相关的内容。
什么让你印象深刻?
不一定是最强大的那个。
我更感兴趣的是那些引入了真正有趣的想法或以不同方式解决问题的项目。
可以是开源、研究、基础设施、编排、记忆系统、代理框架,或任何其他与自主系统相关的内容。
什么让你印象深刻?


我在一家专注于统一上下文层的公司工作,所有内容都在一个原生平台上,等等,所有的营销/销售对话都围绕着代理。似乎没有人真正关心或考虑底下的数据组织。

确实如此。这正是我认为讨论不足的部分。
每个人都想谈论“智能体”,但一旦你试图让它们在真实工作流中发挥作用,价值就开始向下转移到基础设施层:上下文、数据组织、连接器、权限、认证、工具、日志、恢复,以及确保智能体能够在正确的时间访问正确的内容。
智能体是可见的部分,但底层的系统决定了它是可靠工作还是仅仅在演示中看起来不错。

改变我对AI代理应该是什么的看法,拓宽了我对它们的理解。我开始更多地将它们视为员工而非代理。通过将视角固定于此,我不得不以不同的方式设置它们,尤其是为客户端。现在我从问题开始:“我希望这个新员工为我或客户做什么?”将代理视为远程工作者改变了一切:我希望它们如何与我沟通?我可以告诉它们关于公司或我的哪些信息,以帮助它们理解自己的工作?我可以给它们哪些流程和文件,让它们开始学习“被雇佣”的任务?
在一个案例中,这个代理被赋予了公司邮箱、手册和一些电子表格,现在它可以向老板回复投标电子表格,并提出必要的问题进行澄清。它甚至每周向工资部门报告自己的工时。在另一个案例中,被雇佣来创建和改进网站的AI代理被赋予了一个目标,并被告知不再期待更多输入,而是要将网站打造成该领域最好的。它每天在网站上工作,并评估输入以知道该做什么,例如流量较多的主题、流量不足时的SEO改进、回复访客的邮件输入。
如果我们要区分AI代理和现有的半自主工具(如CODEX、Claude Code等),那么这些AI代理应该如何被不同地使用?我的方向是,为了让它们被不同地使用(假设带来更大的好处),我需要以不同的方式对待和看待它们,即像对待一个热情、学习能力强的人一样。
过去一年,我一直生活在这个领域的基础设施方面。(完全披露:我正在构建一个名为 PipesHub 的开源项目)。
关于你提到的以不同方式解决问题——我们注意到,现在每个人都痴迷于构建更好的推理框架和智能体循环。但我们发现,即使是最聪明的智能体在生产环境中也会因为一个基本原因而完全崩溃:它无法轻松访问或理解混乱、孤立的公司数据。
我们非常厌倦为了回答一个基本问题而构建自定义数据管道,因此我们决定构建一个专用的上下文和检索层,它位于你使用的任何框架之下。
对我们来说,架构上的转变是放弃了“只使用向量数据库并将块转储到提示中”的方法。我们将知识图谱与向量搜索结合起来。这样,智能体实际上驱动自己的检索——如果需要硬性指标或关系,它会访问图谱;如果需要广泛的上下文,它会拉取文档。
整个目标是尽可能将首次价值实现时间降至零。我们开源了核心引擎,以便开发者可以直接获取仓库并在本地启动架构进行测试。
如果你们正在深入研究自主系统的内存和数据基础设施方面,我希望你们能查看一下仓库,并告诉我这种上下文处理方法是否对你们有意义。
对我来说,最近最有趣的方向是代理基础设施,而不是代理本身。
规划和记忆很酷,但真正的瓶颈似乎是连接层:OAuth、令牌、API范围、本地密钥、安全执行、重试,以及确保代理能够实际使用真实服务而不会泄露凭据或破坏工作流程。
不如新框架那么引人注目,但可能更接近让代理在实践中变得有用的关键。