不从模型开始构建AI代理
摘要
本文探讨了Proyecto Chatty项目关于构建具有连续性的AI代理的研究,重点围绕模型周围的系统,包括上下文、记忆、工具和权限。
来自Proyecto Chatty的研究笔记及Mendel的创建
很长一段时间以来,我以一种如今看来几乎显而易见的方式使用人工智能工具:打开对话,提出问题,得到回答,然后关闭窗口。#AI可以帮我思考、研究或写作,但工作的连续性仍然取决于我自己。我必须记住之前的决策、检索文档、重新解释上下文并决定哪些信息仍然有效。然后出现了一个问题:要让人工智能不再仅仅是一个响应工具,而是开始作为一个具有连续性的代理运作,需要改变什么?这个问题催生了Proyecto Chatty。
它并非始于一个平台、一个应用或一个商业产品。它始于一项实践研究,探讨如何利用我们已有的工具构建代理。初始假设相对简单:代理不仅仅是通过选择一个好模型来构建的。它是通过设计一个系统来构建的,该系统决定了它知道什么、记住什么、能做什么、如何证明它做了某事以及何时应该停止。
代理不仅仅是带工具的聊天机器人
“代理”一词目前被用来描述相当不同的系统。在某些情况下,它仅仅是一个连接到某个功能的聊天机器人。在其他情况下,我们谈论的是能够进行研究、使用工具、修改文件、执行进程并以一定程度自主性继续工作的系统。
对于Proyecto Chatty,当出现多个协调的能力时,代理就开始了:
代理 = 模型 + 上下文 + 记忆 + 工具 + 权限 + 框架 + 评估
模型提供推理和生成。但模型本身并不构成代理。我们还需要定义:
它为任务接收哪些信息;
它必须检索哪些之前的决策;
它保留哪些知识;
它可用哪些工具;
它使用哪些权限;
哪些操作需要批准;
如何验证工作已完成;
当某事失败时会发生什么;
何时应该继续、询问、停止或升级问题。
这种区分很重要,因为它改变了我们的初始问题。我们不再问“哪个模型更好?”,而是开始问:需要什么样的系统围绕模型,才能使其工作可靠、可恢复并随时间有用?
模型周围的结构
在设计Proyecto Chatty时,我们分离了不同的层次。
1. 目标
每个代理都需要一个足够清晰的功能。仅仅说“研究”、“帮助我”或“自动化事情”是不够的。必须定义它试图解决的问题、我们期望的结果以及哪些决策仍由人类控制。一个模糊的目标会产生可能工作很多但并未真正接近我们需要的东西的代理。
2. 上下文
代理必须为每个任务接收足够的最低上下文。太少的上下文会导致错误和重复。太多的上下文会增加噪音、成本和矛盾的可能性。因此,我们采用了渐进式检索:代理从一个小入口开始,仅在任务需要时查询额外信息。
3. 记忆
记忆并非保存一切。一个保存每次对话、结论和草稿的系统最终会积累矛盾、过时信息和不再代表当前状态的决策。因此,我们区分:
原始来源;
衍生知识;
操作状态;
决策;
可重用的程序;
测试;
事件;
历史资料。
记忆必须保持连续性,但也必须有来源、有效性和遗忘能力。
4. 工具
代理可以搜索信息、阅读文档、写入文件、查询API或执行进程。但拥有一个工具并不意味着拥有永久权限以任何方式使用它。这导致我们将通常混合在一起的四个元素分开:
能力;
工具;
权限;
计划或日程。
能力解释如何完成任务。
工具允许执行它。
权限定义可以到达哪里。
日程确定何时采取行动。
5. 框架
框架——或称harness——是围绕模型的系统,它建立模型可以工作的条件。包括:
完成标准;
尝试次数限制;
验证;
可追溯性;
错误处理;
恢复;
升级条件;
人类批准;
回归测试。
模型可以决定如何处理任务。框架决定在什么条件下可以继续行动。
6. 评估
代理最常见的问题之一是它们可以声明成功,而未证明结果存在或有效。因此,我们采用了一个简单的模式:操作 → 证据 → 继续决策
如果编写了文档,必须重读。
如果修改了系统,必须测试。
如果研究了主张,必须保留来源和矛盾。
如果操作产生外部效果,该效果必须可观察。
一个有说服力的回应不等于正确的执行。
我们如何构建它
Proyecto Chatty并非始于庞大的基础设施。我们使用易于获取的工具:
#ChatGPT 作为推理、设计和协调空间;
#Google Drive 作为规范的操作记忆;
AI_Workspace 作为状态、决策、测试和事件的结构;
#Obsidian 作为探索和关系空间;
#Python 和本地工具当我们需要执行时;
开放源代码和免费服务尽可能使用。
我们的决定是先处理人类可读的文档。我们可以从向量数据库、图数据库、多代理系统或专用框架开始。我们不排除这些可能性,但我们希望避免在理解要解决的具体问题之前构建基础设施。
每个新组件必须回答两个问题:
它减少了什么真实问题?
它引入了什么复杂性?
这个原则帮助我们避免了一个常见的陷阱:创建更多机制来控制其他机制,直到代理最终陷入自身的官僚主义。我们称之为反过度框架原则。
为什么不用简单的代理框架?
框架可能非常有用。问题不在于使用它们,而在于在理解我们需要的架构之前就采用它们。在选择技术之前,我们想回答更基本的问题:
什么是真实的来源?
哪些信息应该在模型之后生存?
我们不想委派哪些决策?
我们如何区分来源和解释?
什么时候经验可以变成规则?
我们如何防止明显的改进降低控制能力?
我们如何在不失去代理连续性的情况下替换模型?
我们的意图是让Chatty不完全依赖于特定供应商或模型。模型可以更改。记忆、程序、决策、测试和代理的操作身份应该能够保持。
Mendel:我们的第一个真实代理
Mendel是基于Proyecto Chatty原则构建的第一个代理。其目的是检测信号、研究、对比来源、制定假设、发现关系并保存有用的知识。但Mendel不仅仅是一个自动新闻搜索器。我们正尝试让它能够区分:
注意力与重要性;
主张与证据;
重复与证实;
原始来源与衍生内容;
孤立事件与结构性变化;
有趣的假设与有足够支持的结论;
知识
相似文章
从构建AI代理中学到的教训
作者反思了构建AI代理的过程,强调了诸如输出不一致、上下文管理以及在适当时候使用确定性方法的重要性等挑战。
@svpino: 如何构建一个随时间不断改进的智能体:智能体可以从三个方面学习:1. 模型:仅适用于……
Santiago Valdarrama 分享了一个构建 AI 智能体的框架,该框架通过三个学习领域(模型优化、工具链优化和上下文积累)来让智能体随时间不断改进,并强调了从用户修正中学习的重要性。
@yoheinakajima:非常棒的文章,主要聚焦于 coding agents,但个人认为也适用于其他领域。与我之前的许多想法不谋而合:- agent…
该推文总结了构建 agent systems 的关键原则,着重强调了 scaffolding、memory 与可复用工具,内容基于 Yohei Nakajima 的一篇文章。
我一直在尝试自定义智能体,有趣的部分并非任务完成,而是它们拥有记忆后发生的变化
作者反思了实验自定义 AI 智能体的经历,指出长期记忆和连续性将智能体从简单的任务执行者转变为具有“稳定倾向”的持久协作伙伴。这引发了关于智能体“个性”的价值与工作流程中控制、可靠性和可审计性需求之间的矛盾的问题。
我认为AI代理的讨论即将超越框架层面
作者认为构建AI代理不再是难点;真正的挑战在于部署、测试、版本控制和运维管理,这些在生态系统中仍然支离破碎。