#智能体

AI Agent 到底是什么?从 Jennings 定义谈起 “AI Agent”这一术语虽在近年大热,但其核心概念早已由 Nicholas R. Jennings 与 Michael Wooldridge 在 1995 年的《Intelligent Agents: Theory and Practice》中系统确立。他们将“智能体”定义为:一个嵌入特定环境中的计算系统,能够在该环境中自主行动以实现其设计目标。这一定义成为多智能体系统(MAS)研究的基础,并提出四项衡量智能体的关键属性:自主性(能独立运行)、反应性(感知并响应环境变化)、前瞻性(基于目标采取主动行动)与社会性(能够协作与沟通)。 然而,在当下的工程实践中,要真正实现这四大属性仍具有相当高的难度。尽管 ReAct、AutoGen、LangGraph、CrewAI 等主流框架纷纷打出“Agent”旗号,它们多数仍停留在“语言模型 + 工具调用”的阶段,缺乏结构化的状态封装、计划机制与交互协议。这些系统通常依赖自然语言记忆作为状态存储,对环境的感知局限于文本输入输出,目标与计划的建模大多被简化甚至省略,而协作机制也往往停留在对话模拟层面,缺乏真实的社会行为协议与组织控制结构。 换句话说,当代 LLM Agent 多数只能在表层满足 Jennings 框架中的“工具调用”与“表面协作”,而在真正的状态感知、计划能力、环境互动与协作协议等方面仍存在明显工程落差。它们更像是 prompt 的包装器,而非具备认知与调度能力的结构性智能体。 要真正构建接近 Jennings 理想的 AI Agent,必须引入可解释的状态模型与持久记忆结构、明确的计划调度机制、标准化的交互协议以及多轮对话中的身份与行为一致性。只有当智能体具备了这些结构能力,它才不再是一个被动执行的语言函数,而是一个真正能够协同、规划、反应并自主演化的结构系统单元。 真正的智能体到底值不值得投入研究?还是说,它会不会最终成为一个耗尽心力、却注定走入死胡同的幻象? 这个问题越来越像一面照妖镜。现实世界里,有太多曾被寄予厚望的底层技术,最终悄无声息地被市场淘汰、被工程复杂性吞噬。Jennings 所定义的理想型智能体,正面临类似的命运风险。它拥有令人敬畏的结构理想—— 🧱 结构性:每一个模块边界清晰、可组合、可迁移; 🧠 状态性:具备可追踪、可持久、可调度的运行状态; 💾 记忆性:融合语义唤醒与行为经验的双系统记忆机制; 🧭 路径性:支持非线性、多策略、可重构的执行结构; 🤖 调度性:能够统一调度工具、任务、子 Agent; 🔁 自演化:具备反思、失败容忍、成长与优化能力。 这简直就是我心中最理想的“结构人格”,我是无比憧憬的。这个甚至能完美解决上下文的问题。 看起来无比完美,却让人光是读完就头皮发麻。工程难度极高,构建成本惊人,调试流程复杂,状态不可控,行为难以解释。我也怀疑:这样一个理想结构真的能落地吗?它真的有价值吗? (2/n)
从分布式认知到智能体沙盒:上下文工程的前世今生 我们一直在追问一个问题:“上下文”到底是什么? 在大语言模型时代,“上下文”似乎成了万物解释器。它是 prompt,是历史,是 token,是 memory,是一切的因。但真正追溯起来,这个词不过是现代工程视角下的临时叫法。在历史长河中,人类从未依赖固定术语来传达概念。意义的表达,一直是动态的、时代性的、多义的。 我知道有人会在推特上不断争论名词定义,纠结术语本体,害怕说错话。其实你会这么焦虑,是因为你还太年轻。你还没来得及在图书馆把所有能读的书都翻过一遍,没啃完泛读课几千张的试卷,也没刷过晋江论坛上一万篇看起来无聊却构成语感基础的网络小说,更没读够《哈利波特》的一百种同人演绎版本,不管恶心还是不恶心的,我都看完了。你还没有亲身验证过:人类的认知,不靠术语确证,而靠结构对齐。 工科生也要多读点文学。读书破万卷,下笔如有神。 不同的时代用不同的话说同样的事。今天你说“上下文”,十年前的人也许说“语境”,更早的人说“记忆”,结构主义者说“框架”,认知心理学者说“图式(schema)”,而《Cognition in the Wild》会说“文化任务系统”。语言在变,但核心的问题没有变:我们如何在系统中保持连续性、追踪状态、组织行为? 上下文不是术语,而是时代对“认知调度结构”的一种指认方式。而我相信,大语言模型的下一个关键跃迁,不会来自模型本身的微调、参数堆叠或幻觉率的下降,而是来自“上下文工程”作为系统性结构工程的确立。这不是拼 prompt 的技巧,而是构建结构、规划路径、调度智能体、维持状态协同的全过程。 从 Hutchins 的分布式认知,到 Minsky 的心智社会模型,再到今天的多智能体沙盒(如 Smallville),其实探索的是一个问题。我们说说 Hutchins 的分布式认知。 在 1995 年出版的《Cognition in the Wild》中,认知人类学家 Edwin Hutchins 提出了一个至今仍具有颠覆性的观点——认知不是发生在某个人的头脑中,而是分布在整个社会性系统中的。这本书的“野”,并非意指原始或混乱,而是指他所观察的认知行为并非在实验室中进行,而是在自然环境、真实世界任务流程中的发生,比如他田野调查的对象:美国海军舰艇上的导航团队。 Hutchins 研究发现,一个看似简单的任务——导航,并不是某位军官独立思考的结果,而是由多人协作完成的结构性过程。有人读取雷达数据,有人记录数值,有人在图纸上进行计算,信息在他们之间流动,决策才得以形成。除此之外,还有纸笔、坐标系统、专用术语、表格、雷达等外部工具的参与,它们不仅是辅助,而是认知过程本身的一部分。语言、制度、流程、工具、环境,以及人的角色分工共同构成一个动态的认知网络,信息在其中穿梭、被加工、被传递。这意味着,大脑并不是认知的全部,它只是这个更大系统中的一个节点。 Hutchins 完全打破了“认知=大脑”的传统观念。他明确指出,认知是在多个层次上被分布的。首先,它在个体之间分布:认知任务通常不是一个人完成的,而是团队共同完成,每个人只掌握任务的一部分。其次,它在内部与外部结构之间分布:认知不仅存在于人脑中,还依赖于图纸、表格、工具,这些物理媒介实际构成了“外部记忆”。最后,它也在时间上分布:一个人的认知行为依赖于之前团队留下的结构和制度遗产,比如流程图、记录规范、指令格式等,它们都是认知的延续性基础。 这一理论,与 Marvin Minsky 在《Society of Mind》中提出的观点形成惊人共鸣。如果我们把 Hutchins 所说的“人在协作中的功能单位”理解为 Agent,那这就是一个运行在真实世界中的 Agent 系统。而他所说的“外部工具系统”则对应当代 AI 系统中由 RAG、数据库、图谱所组成的记忆补全机制。甚至时间上的认知延续,也可以理解为多智能体系统中长期计划与路径依赖的体现。 说到底,Hutchins 向我们揭示了一个根本性的真相:认知不是个体思考的能力总和,而是结构化信息流的组织能力。真正决定智能的,不是单个 Agent 有多聪明,而是这些 Agent 是否处于一个能支持信息流动、反馈、协调、演化的系统中。认知是一种“被调度”的结构过程,是一种嵌入式、路径化、可追踪的信息动态,而非脑内静态存储的内容。 他实际上为我们提供了一种语言模型时代“上下文工程”的最早形态:不是堆叠上下文,而是组织路径;不是增大参数,而是优化流动;不是强调理解,而是调度结构。 如果我们把 Edwin Hutchins 的《Cognition in the Wild》重新理解为一场沙盒模拟实验,就会发现,那艘军舰,其实就是三十年前的 Smallville——只不过它没有像素地图,没有代码,没有 LLM,却已具备全部结构要素。Smallville 是斯坦福团队 2023 年推出的多智能体模拟项目(Generative Agents – Smallville),在其中,每个角色都是由大语言模型驱动的认知个体,具备记忆流、计划能力与反思机制。 当他们在咖啡馆偶遇时,并不会访问全局知识,而是检索各自的片段记忆,基于当前场景与意图做出行为决策,并将对话与动作反馈回自己的记忆系统。事件通过语言传播,行动彼此影响,个体间的协作并非中心化控制,而是由意图触发,逐步组织,最终形成如 Valentine’s Day Party 那样自发出现的社会性行为。 回过头看,Hutchins 所描述的军舰系统就是一个没有计算平台的 Smallville 原型。人类成员承担 Agent 的角色,雷达是传感器,纸笔是外部记忆体,术语是通信协议,时间流程是结构化路径,整套认知行为并不是由某一个人单独完成的,而是分布在整个系统中的任务分工与信息流转之间。它的“上下文”从来不是某一段文字、某个人的记忆或某个模型的输入窗口,而是由角色、工具、任务、流程、制度、状态等维度共同构成的动态认知结构。它是一张可以流动、传递、反馈、演化的认知路径网,是结构意义上的上下文,而非语料意义上的上下文。 从这个角度看,Hutchins 实际上提供了一种极具前瞻性的认知沙盒设计思想:上下文不应该是被记住的内容,而是被调度的结构单元;结构不应该压缩进个体,而应该流经路径、联动角色、触发工具、反馈结果;智能不应该被定义为某个 Agent 的思维能力,而应该被定义为信息能否在一个系统中完整走完一条闭环路径。 这种理解直接反转了当代大模型系统中常见的误区——我们试图让一个超级 Agent 理解全部上下文,就像让一个人同时记住整个小镇的一切,而真正需要的不是更强的单点记忆力,而是更清晰的结构协作图谱。Hutchins 和 Smallville 一起告诉我们:我们不需要一个全知大脑,我们需要一座结构良好的小镇。
宝玉
1个月前
转译:为什么生成式 AI 编程工具和智能体对我没用 作者:Miguel Grinberg 人们总是问我,我是否使用生成式 AI 工具来编程,以及我对它们有何看法。因此,我决定将我的想法写下来,这样以后再有人问起,我就可以直接把这篇文章甩给他们,而不必每次都重复自己的观点。 从标题你大概已经猜到,这不会是一篇吹捧 AI 的博文。但它也不是一篇反对 AI 的文章,至少我不这么认为。市面上已经有太多 AI 吹和 AI 黑写的文章了,我觉得没必要再多我这一篇。虽然在这个话题上我绝非中立,但在这篇文章里,我只想从纯粹技术的角度,分享我个人使用这些工具的真实体验。 AI 并不更快 说真的,生成式 AI 工具对我没用的最主要、也是最重要的原因是:它们并没有让我写代码变得更快。就这么简单。 使用生成式 AI 编程工具来为我写代码,听起来很容易。如果是一个 AI 智能体,那就更方便了,它在我做别的事情时就能直接编辑我的文件。原则上,这一切听起来都很美好。 但问题在于,我需要为这些代码负责。我不能盲目地把它们添加到我的项目中,然后祈祷一切顺利。只有在我彻底审查并确保完全理解了 AI 生成的代码之后,我才可能将其整合进我的项目。我必须有信心在未来能够修改或扩展这段代码,否则我就不能用它。 不幸的是,审查代码实际上比大多数人想象的要困难得多。审查一段不是我写的代码,至少要花掉我与亲手写这段代码相同的时间,甚至更多。我们行业里有句名言,大意是“读代码比写代码更难”。我记得最早将此概念理论化的人是 Joel Spolsky(Stack Overflow 和 Trello 的创始人),在他的文章《有些事你永远不该做,第一部分》中提到了。 你可能会说,可以把 AI 写的代码当成一个“黑箱”。我想,你可以说服自己,只要代码能按预期工作,就可以安全使用,无需审查,这样就能提升一些生产力。但在我看来,这是极不负责任的,因为如果这段代码将来出了问题,AI 是不会承担任何责任的。无论有没有 AI,我永远是我产出的代码的第一负责人。在我看来,承担如此巨大的风险是疯狂的。 这一点在我从事的某些工作中尤为重要,因为这些工作涉及签署合同、法律义务和金钱交易。如果我是以专业人士的身份被雇佣,那我别无选择,只能做到专业。AI 工具无法帮我赚更多钱,也无法让我在更短时间内完成工作。我唯一能通过它实现这些目标的方式,就是牺牲工作质量并引入风险,而这是我绝不愿意做的。 AI 不是生产力倍增器 我听过有人说,生成式 AI 编程工具对他们来说是生产力的“倍增器”或“赋能器”。基本上,持这种观点的人声称,使用生成式 AI 后,他们能工作得更快,也能处理更复杂的问题。可惜的是,这些说法仅仅基于使用者自身的感觉,并没有确凿的数据来支持。我猜,或许有些人审查代码的效率比我高,但我对此表示怀疑。我认为真实情况是,这些人之所以能节省时间,是因为他们只对 AI 生成的代码进行抽查,或者干脆跳过了整个审查阶段——正如我上面所说,这对我来说是绝对无法接受的。 另一个我常听到的论点是,当你需要用一种不熟悉的语言或技术编写代码时,生成式 AI 会很有帮助。对我来说,这同样没什么道理。作为一名软件工程师,我最享受的部分就是学习新事物,所以“不懂”从来都不是我的障碍。你越是练习学习,学习的速度就会越快、越容易!近年来,我为了不同的项目,不得不学习了 Rust、Go、TypeScript、WASM、Java 和 C#,我绝不会把这个学习的过程委托给 AI,哪怕它能帮我节省时间。当然,它也省不了,原因还是上面那些——我要为我产出的代码负责。抱歉,我在这点上有点啰嗦。 AI 代码不同于人类代码 前几天我和一个朋友聊起这些观点,他问我,既然如此,为什么我乐于接受人们为我的开源项目所做的贡献呢?那些不也是别人写的代码吗?为什么人类写的可以,AI 生成的就不行? 真相可能会让一些人感到震惊:用户提交的开源贡献其实也并不能节省我的时间,因为我同样觉得必须对它们进行严格的审查。但是我享受与那些对我的项目感兴趣并花时间报告 bug、请求新功能或提交代码修改的用户合作。这些互动首先是新思想的源泉,它们直接帮助我把工作做得更好。这正是我热爱开源工作的地方! 我的朋友仍然不服气,他建议我可以并行启动一堆 AI 智能体,为我所有未解决的 bug 创建拉取请求(PR)。“这会改变游戏规则的!”他说。不幸的是,这只会花掉我的钱,并且可能让我变得更慢,原因已如前述。即便我们假设 AI 编程工具已经足够成熟(实际上还差得远),能够在很少或没有监督的情况下修复我项目中的问题,我仍然是那个瓶颈,因为所有这些代码在合并之前都必须经过我的审查。 AI 编程工具唾手可得,其不幸的一面是,现在一些用户也用它们来生成低质量、敷衍了事的拉取请求。我已经收到过一些这样的 PR,有趣的是,当我开始阅读那些未经真人编辑和润色的 AI 代码时,一种“恐怖谷”效应在我心中油然而生。当我遇到这类 PR 时,我会开始向提交者追问他们代码中那些奇怪的部分,因为我认为他们需要为自己想要合并的代码负责。但他们,通常很少回应。 AI 不等于实习生 许多 AI 倡导者说,你应该把你的 AI 编程工具当作一个渴望取悦你的实习生。我认为说这话的人,大概从没带过实习生! 在初期,将工作委派给实习生会导致你的生产力下降,原因和我上面列举的差不多。实习生需要大量手把手的指导,他们产出的所有代码在被接受前都需要仔细审查。 但是,实习生会学习并随着时间的推移而进步。你花在审查代码或向实习生提供反馈上的时间并没有被浪费,这是对未来的投资。实习生会吸收你分享的知识,并将其用于你之后分配给他们的新任务中,随着实习期的推进,对他们进行密切监督的需求会逐渐减少。最终,实习生常常因为成长为成功的独立贡献者而被公司聘为全职员工。 而一个 AI 工具,最多只能算是一个患有“顺行性遗忘症”的实习生,这可不是什么好实习生。对于每一项新任务,这个“AI 实习生”都会重置回原点,什么也没学会! 结论 我希望通过这篇文章,我已经清楚地阐述了我在工作中应用生成式 AI 编程工具时遇到的技术性问题。 根据我的经验,AI 编程这回事,天下没有免费的午餐。我相信那些声称 AI 让他们更快或更高效的人,是为了实现这些收益而有意识地选择放宽了他们的质量标准。要么是这样,要么他们这么说,只是因为他们自己能从向你推销 AI 中获利。