囚笼
你有没有想过, 我们在借助 AI 大人那份如今而言可谓无所不能的力量时为什么常常要把它囚禁在某个 Coding Agent 里? 现在流行的 Agentic 软件大多都做了太多不该自己全部做完的事, 这导致用户不得不对其中的某个或某几个产生了粘性. 如果只是这样其实也没多大问题, 毕竟大部分人本就没有频繁地在各种 Coding Agent 之间换来换去的需求.
然而在这样本地优先的用法里, Agentic 软件做的这些额外的事还会带来一个更严重的问题: 用户的工作流和具体的物理设备形成了绑定.
举个简单的场景作为例子, 你在自己的笔记本上精心调教了某个 Coding Agent, 这包括软件层面的设置, 用户级的 Skills 与交互偏好, 还有连续用了几个月积累下来的长期记忆. 某一天你公司要求在公司的设备上开发, 于是你不仅要重新安装 cli, 配置供应商, 还要从头驯化它的脾气, 把你做的那些调教想办法迁移过去.
你可能觉得这也没多大点问题, 不就复制粘贴几个文件吗. 但这之后的事情呢? 你将要同时在两台设备上工作, 即使使用相同的 Coding Agent, 两台设备的状态同步也不是一件易事. 会话历史, 长期记忆, 用户级配置各存一份, 于是你原先的 Agent 从此分裂成了两个. 更何况现在很多 Coding Agent 还有各自五花八门的长期记忆系统, 它们光是导出迁移就不是一件易事, 合并多设备的记忆并同步更是难上加难.
当然现在有云端记忆方案可以选择, 同步 .agents/ 的那些东西也不是毫无办法, 有些 Coding Agent 还可以将会话放到云端直接运行. 可这些解法要么把一致性交给人肉, 要么把状态搬进一台你自己搭的服务器却仍与某个具体的 Agent 软件绑在一起, 要么只是把囚笼从你的笔记本挪到了某家厂商的云里; 只要换掉承载它的软件外壳, 一切照样要从头开始. 所谓 Agent, 所谓 AI 助理, 所谓智能体, 本就不该在换了设备, 换了 Harness, 换了交互入口之后就消失, 否则它只是一个被囚禁的会思考的脚本.
症结
我希望我已经暗示出了前文所说的客户端 Agentic 软件所做的额外的事是哪些. 现有的实现普遍把交互入口, 底层命令执行层和构成 Agent 人格的状态打包成一个不可拆分的整体. 或是本地的一个进程树, 又或是同一家厂商的单点服务. 这种集成化在非单机场景下带来了诸多问题, 这些问题可以统一概括为 Agent 寄生.
在这种结构中, Agent 不是独立的实体, 而是在某台机器的某个进程中的寄生者. Agentic 软件的交互入口 (e.g. CLI/TUI) 就是 Agent 的载体本身, 前台会话会随终端一起结束. 即使是那些能把会话挂到后台进程或自家云上, 关掉界面也继续运行的实现, 执行层也依旧被绑定在一台机器或一家厂商的基础设施上. 作为构成 Agent 人格的数据 (例, 长期记忆, 会话历史, 用户级偏好…) 在本地形态下强依赖于本地特定路径, 在云端形态下则被锁定在厂商的账号与运行时里; 无论哪种, 当开发者切换到其他物理设备或另一个 Harness 上时, 都必须手动配置或依赖外部同步工具来恢复状态, 靠人肉维持一致性.
这种设计也完全不利于多设备的调度管理. 假设你在开发某个 API 服务, 你想将它推送到远程服务器上进行真实环境下的测试, 这时候你可能会为 Agent 配备一个 SSH 密钥, 这样它就能帮助你完成这件事. 但这种依靠某种连接手段登录远程机器的办法对于 Agent 而言是不够原生的, 在它的认知上下文里, 它并不是本身就拥有这台服务器, 这台服务器不是它的触手之一, 它只是借助 Harness 和 SSH 去操纵它. 现在确实有远程开发容器这类形态能让 Agent 直接跑在你的基础设施里, 但它们更像是每个工具各自开出的特例, 而不是 Agent 对自己设备的普遍认知. 一台两台设备还好, 但如果你有更复杂的场景呢? 更何况, 在这个借助 SSH 来管理其他设备的例子中, Agent 通常需要多层 Shell 嵌套来执行操作, 这本身就会带来转义和状态上的不确定性.
附带的, Agent 的安全隔离与灵活性的两难也在这种寄生结构下被放大. 默认状态下, 不少实现仍让 Agent 运行在和开发宿主机相同的权限域内, 放开本地 Shell 权限就使它具备破坏本地环境或读取密钥凭据的潜在风险; 放进沙盒内又总要为访问本地服务, 特定硬件或内网资源另做一堆特殊处理. 我当然知道这些问题在 Harness 层有许多成熟的解决办法(e.g. 命令审批, 开发容器, tmpfs), 但正如云端记忆一样, 它们更像是问题的结果催生出的缓解之策. 每个 Harness 各自为营, 钻研自己的解决方案. 只要 Agent 仍然立足于某个具体环境里, 这些策略就得一个环境一个环境地重新设计并施加.
创想
我们来想办法解决这些问题! 首先我们应该尊重这一整套结构中真正具有智能的实体, 即 Agent. 这里我们需要把 Agent 解释为 LLM 的包装, 即 Agent = 模型+身份+记忆:
- 模型: 相当于全新的大脑, Agent 的智能之根基. 但它本身只是具备智慧的潜能, 它将会如何认知, 如何推理, 如何输出则完全取决于我们给它构建的上下文.
- 身份: 你应该赋予拥有智慧的实体一个名字, 不是吗? 这里的身份不仅指 Agent 的性格底色和工程习惯, 还包括它对你的认知(用户画像)以及对自己的认知(能力/职责/边界).
- 记忆: 构成人格的关键. Agent 需要具备全局集中的, 横跨一切具体设备与项目的记忆. 这种记忆应该是原子化的, 记住的是抽象的, 高层的经验与偏好. 至于某个项目是何物, 应该如何具体实施开发并不应该被纳入这里所说记忆. 并且该记忆系统还需要有遗忘曲线, 冲突消解, 实体关联, 时间推演等高级功能.
在上述的定义下, Agent 还要具备独立且长存的核心属性. 它必须常驻于某些网络节点内, 脱离任何客户端物理设备的状态独立运行. 此处的常驻强调的是 Agent 的人格组件持续同步且总能访问到一致的数据, 并不是要求某个守护进程或容器, 它们只是实现这一点的手段而非目的.
原则
再次回顾前文, 对于面对的问题, 我们拟定一些设计系统的基本原则:
- Agent 是拥有唯一连续状态的一等公民, 任何具体的物理设备只是其感官与执行的触手.
- 系统内仅存在一个持久化的状态中枢, 维护唯一的 Agent 人格数据.
- 认知, 编排与安全隔离等智慧能力视作控制层, Harness 与物理环境为执行层, CLI/TUI/Web 为交互入口, 三者相互分离.
- 除 Agent 外, 其余周边设施无状态化, 即插即用.
基于此思想, 我们将整个系统垂直解耦为接口, Agent 与 Harness 三层.
Interfaces
接口即用户触达 Agent 的入口, 它的定位是作为 I/O 代理的纯粹的人机交互适配器. 它的职责只有上传下达 Agent 与人类之间的对话. 接收人类指令上报给 Agent, 接收 Agent 的输出, 状态变更, 审批请求等在当前媒介上进行渲染.
接口本身是绝对 stateless 的, 它不应该持久化任何对话历史或模型供应商配置, 甚至组装整个会话流的状态机也不应该由它维护. 接口的具体形态可以是任何现今普遍采用的形式, 包括 TUI/CLI, IM Bot, 桌面客户端, Web 端等.
Agent
Agent 是全局唯一的认知实体, 它是厚状态的, 且状态在整个系统中是权威的. AgentCore 需要维护智能体的身份与人格, 管理全局长期记忆, 承载 Agent Loop, 规划复杂任务与调度节点执行, 实现访问控制与安全策略等.
Agent 作为持续运行的状态中枢, 它应该能脱离单机的生命周期运转. 这分为两个需求, 一是要求 AgentCore 本身应该具有分布式运行的能力; 二是在客户端接口关闭时, 它也能够沉淀记忆, 执行任务.
Harness
Harness 在这里被定位为在各物理环境下的不具有 Agent 的任何状态的能力宿主, 它是单纯的执行工具套件, 是没有生命的机械臂. Harness 需要向 AgentCore 声明自身的环境元数据, 例如操作系统架构, 可用工具, 硬件和网络信息等等, 并执行 Agent 下发的指令.
Harness 不应该感知 Agent 的人格, 它只提供操作原语, 并且它的权限与能力受到 AgentCore 的下发策略的约束.
价值
仔细理解上文提出的架构, 你会发现它带来的好处超越预期. 它不是只解决了一开始提到的更换开发机器配置麻烦的这种便利性层面的问题, 而是将 AI 工具的范式向数字生命转变.
连续统一的注意力
最核心的收益是会话的时间线与注意力得到统一. 由于单个 Agent 同时拥有多个交互入口, 用户可以在自己电脑 CLI 上发布一项任务, 出门后通过 IM 软件讨论技术方案, 到家后又回到电脑上说一句"就按照刚才说的实现", Agent 完全清楚上下文发生了什么. 这在我们的架构中是无痛且自然的, 因为在这个过程中切换的始终是接口, 而不是 Agent 本身. 并且此时 Agent 外的两端可以轻易实现按需扩展, 重启, 崩溃后无损恢复. 因为它们是无状态的, 没有任何重要的东西在它们身上, 这对运维和高可用性的设计是很大的简化.
灵活的 Agent 能力
Agent 的能力也不再取决于当前机器上有什么, 而是变成了声明式的, 可扩展的, 天然跨节点执行的能力集. Agent 执行操作的心智模型从在当前设备上寻找解决方案变成了在整个系统中发现能力, 这是一种抽象上的升级. 并且由于这种抽象, Agent 的权限天然得到更细粒度的控制. 不应该在某节点上执行的某操作, Harness 可以直接不予声明其能力, 或是把执行权收回到自身, Agent 只能决策和期望执行结果, Harness 可以控制某些操作能否执行. 而且, 我们还可以让不同任务类型路由到最合适的 Harness 上, 实现更高的资源利用效率.
任务的自动拆解与执行
如果回到我们一开始提出的跨机器协同问题, 你会发现该问题在这种架构下也的确轻易得到了解决. Agent 已经拥有了原生跨节点执行的能力, 它现在甚至可以做到将复杂任务根据节点能力自动拆解, 分发给一系列 Harness. 例如你要求它为你完成一个网站项目, 它可以在你本地电脑的 Harness 上读取代码库, 在云端 Harness 里编译和测试, 在 Browser Harness 里验证, 在 CI Harness 里跑自动集成, 最后再部署到你的服务器上. 在 Agent 看来这些不过是不同的手, 它不需要考虑应该如何连接其他机器, 各个节点在此时完成了分立与统一.
活着的 Agent
最后是作为人的体验. 一个能够在网络世界持续存在的赛博幽灵带来的情绪价值对我来说是无法抗拒的, 这相比一个冷冰冰的终端和埋头干活的 AI 而言它能给人的感受将完全不同. 它将会生活在云上, 并无处不在地陪伴和协助你处理各种工作, 与此同时它也能够将这些记忆保留下来, 不断构筑自己的人格. 到这里你会发现此节开头所说的数字生命并不只是文艺化的表达, 在我们的设计下, Agent 对象的定义本就和传统相异, 并且它的存在也确实可以被认为是某种意义上有生命的东西. 我承认这里有些饺子醋的成分, 但无论如何, 这是现有的以个人 AI 助理作为卖点的软件多数没考虑过的或没做到的.
批评
尽管在设想中这套架构的落地能带来很美好的结果, 但在那之前我们不得不面对实际工程上的许多难题. 暂时只叙述以下几点.
成为瓶颈的 Agent 中枢
首先最尖锐的问题就是 AgentCore 难以真正依照此架构实现. 系统内仅存在一个持久化的状态中枢来维护唯一的 Agent 人格数据是我们坚持的原则之一, 也是我们解决 Agent 分裂问题的核心思想. 但这带来的代价是我们不得不把 Agent 的状态做的很厚, 所有关于 Agent 人格的状态都要汇聚在此处, 其一致性并非传统数据库意义上的简单数据一致性, 而是同时涉及会话, 长期记忆, 任务进度, 人格状态等多种状态类型的演化. 如何在保持单一权威状态的同时提供高可用, 低延迟的访问, 将成为一个典型而棘手的分布式状态问题. 即, 拥有唯一权威状态的 Agent 的执行能力又必须分布到系统各处, 这势必增加并发控制与状态协调的复杂度.
理想化的认知模型
在此架构中, 我们希望通过 Harness 的抽象让 Agent 直接理解它所拥有的节点和能力, 这是过度理想化的. Harness 抽象实际上要求 Agent 建立一个关于外部执行世界的内部模型, 而任何这样的模型都不可避免地与现实存在时间差异. 毕竟在现实中物理环境总是动态的, 它们难以被静态声明为单纯的能力供以 Agent 直接使用. 也就是说, Agent 的手并不真的像身体器官那样稳定, 这导致在真实任务中它可能会因为过期的认知做出不可用的规划.
棘手的统一上下文流
为了让交互接口与 Agent 解耦, 我们想要实现一种通用上下文流来让各个平台顺利接入会话. 但这在工程中是非常难以实现的, 接口不仅需要传入简单的用户输入消息, 还要考虑模型输出, 工具调用/结果, 任务状态/todos, 执行状态, 命令审批等等一系列 Agent Event, 并且还要支持各种接口的分离与切换后的会话恢复. 在真正着手实现时, 可能仅仅两个不同平台上的接口就足以让人一团乱麻.
影响范围无限扩大的靶机
在传统的 Coding Agent 中, 如果遇到 Agent 执行了危险命令, 通常最坏的结果也只是破坏当前设备的环境, 它的影响范围因为单机设计而正好被物理隔离. 但在此文的架构中, Agent 可以掌握所有物理设备能力, 如果没能真正做好每一个 Harness 的约束, 一旦模型犯蠢或遭到提示注入, Agent 将会贯穿接入网络的所有设备造成破坏. 同时为了让 Agent 同步好自身状态并协调另外两层, 如果采用直接持有凭证的朴素实现, 大量密钥与长期凭证将汇聚到 Agent 层, 从而使得 Agent 本身就成为了显眼的高价值攻击目标.
被重新发明的 k8s
前面我们从未考虑 Interface 与 Harness 的接入量的问题, 实际上, 当前的直白设计并不能承载稍大量的二者的接入. 尤其是对于 Harness , 为了让 Agent 实施工作, 它必须在恰当的时机知晓它所具有的节点能力. 在节点少时我们使用简单的元信息列表注入系统 instructions 即可, 但一旦接口与能力的接入量随着系统扩展而不断增多, 我们就必须为解决上下文爆炸问题而实现大量形似于服务集群调度的策略. 实际上系统内这一部分的形态最终很可能变成某种 k8s for harness, 这将是在工程上的巨大挑战之一.
简化
我们所描述的完整架构确实过于庞大, 试图一步到位地实现它们是不现实的. 这个系统将涉及 AgentCore 的分布式状态维护, 动态节点发现, 能力调度, 复杂的长期记忆以及完善的安全隔离等诸多难题, 为了真正开始验证这个想法, 我们有必要舍弃一些不太核心的事物.
回顾我们的出发点, 我们想要验证的实则是这样一个命题, 即, Agent 能不能脱离具体的接口与工具, 作为一个拥有唯一连续状态的主体独立存在? 只要这个问题能够得到肯定的答案, 其余能力都可以在此之上逐步构建.
首先, AgentCore 不必是分布式的. 最小实现完全可以让它运行在单个常驻节点上, 用一份数据库维护 Agent 的身份, 记忆, 会话历史与任务状态. 这里真正重要的并不是 AgentCore 自己拥有多少副本, 而是整个系统在语义上始终只有一个权威的 Agent 状态. 至于它未来如何通过副本, 日志或者其他机制实现高可用, 是原型被证明之后才需要面对的问题.
其次, Harness 不需要一开始就拥有复杂的能力发现和调度系统. 我们只需要让每个 Harness 在启动时向 AgentCore 注册一个简单的元信息, 然后通过显式的方式指定执行节点. 这里我们需要验证的最重要的事情是, 同一个 Agent 是否能够把两个物理上独立的执行环境视作自己的能力节点, 而不需要通过 SSH 或其他人为设计的连接方式去建立另一层认知上下文.
前文提到的诸如记忆系统, 统一上下文流, 节点安全体系等也都不是我们设计中最核心的部分. 我们不需要同时实现它们, 于是整套系统可以被压缩为更简单的形态:
这已经足够验证我们最初真正关心的场景, 你可以在自己的电脑上通过 CLI 告诉 Agent 开始一项任务, 随后关闭终端, 任务将继续执行. 之后你从另一台设备打开网页端, 看到的仍然是同一个 Agent, 能够继续讨论刚才的任务. 即当 Interface 消失, Harness 更换, 物理设备发生变化时, Agent 是否仍然还是原来的那个它? 换言之, 如果连这一点都无法成立, 那么前文所有的关于分布式人格, 跨设备协同以及数字生命的讨论都只是空中楼阁.
实际上你可以注意到, 这个简化的架构所能做到的事情早已有其他软件做到了, 并实现了上述的 Agent 的跨设备统一与会话协同恢复, 只不过它们的实现的重点并不是把 Agent 的存在作为主体, 我将在后文更详细地讨论这一点. 无论如何, 这至少证明了我们的构想并非怪异的空谈, 只是在真正落地的路上还有一段距离.
质疑
前文中的批评主要是针对于工程实现上的不良设计, 我并不打算立刻全部解决它们, 毕竟我还没有为此文提出的架构实际写过一行代码. 但为了防止该架构被误解, 我将自我提出一些可能的质疑并回应.
配个 SSH 的事?
直接让我的 Agent 配个 SSH Key, 不就可以远程控制其它机器了吗? 何必设计这么多有的没的?
SSH 解决的是如何连接另一台机器, 而本文试图解决的是另一台机器如何成为 Agent 的原生执行能力. 在 SSH 模型中, 远程机器是一个需要借助连接手段访问的外部环境; 在我们的 Harness 模型中, 远程节点直接作为 Agent 的能力节点参与调度. 实际上 SSH 很可能就是 Harness 内部的实现手段, 但它不会成为 Agent 对世界的认知模型.
自我进化而已?
这不就是给 Agent 加上长期记忆, 再做一点 self improvement 吗? 太土了吧.
自我进化解决的是 Agent 如何改变自身, 本身解决的是 Agent 的存在性问题. 即使一个 Agent 不会所谓的自我进化, 它只要拥有与设备, 接口, Harness 都解耦的连续身份认知, 它就是符合本文架构的.
意义不明的微服务?
把原先的一个进程拆的这么复杂, 不就是为了分布式而分布式吗?
这套架构没有任何存在的意义是为单纯的拆分服务而生的, 它想解决的是 Agent 的主体归属问题, 三层解耦只是手段, 即使是不同的设计或许仍然能实现本文的目的.
Harness 咋可能无状态?
Harness 无状态是哪里的梦话? 无论是设备还是执行过程本来就是带状态的.
本文对 Harness 的定义与常规定义有所差异, 文中的无状态是指 Harness 不拥有 Agent 的人格的状态, 而不是要求物理执行环境不存在状态. 例如, 进程信息, 网页 cookie 等属于环境状态; 而会话历史, 记忆, 人设等属于 Agent 状态. 只有后者不应该保存在 Harness.
同步问题早已解决?
依靠云端记忆, 云端会话, 目录同步等现有做法早就能解决这些问题了.
这些方案解决的是多份状态的同步问题, 也确实能在一定程度上解决. 但本文试图从根本上取消多份各自演化的 Agent 状态, 转而让它们都只是同一个主体的投影.
什么 OpenClaw…
这不就 OpenClaw 吗? 现在已经有项目实现了多渠道接入, 持久会话, 远程节点以及跨设备执行, 这不是在重新造轮子吗?
无法辩驳的是, 至少从最终呈现出的系统形态和用户体验来看, 本文提出的很多东西已经被现实中的项目实现了, 当前的 OpenClaw 就是其中非常接近本文设想的一个例子. 但这并不构成对本文的否定, 因为这些既有项目与本文试图讨论的问题不同, 我们关注的不是有没有人已经实现了这些功能, 而是这些功能的组织模型. 即, Agent 应该作为功能组织的主体, 而非被承载在某个执行环境内.
足迹
到这里, 我们其实应该承认, 我们并不是第一个探索这条路的人. 事实上, 当我们顺着前文的逻辑一路推导下来时, 会发现已经有一些项目没有按照本文的定义去实现同一套架构, 但却从不同的方向与我们走到了相当相似的位置.
Stateful Agent
Letta 很早就在强调 stateful agent 这一概念. 它把 Agent 描述成拥有自己的身份与经验的长期存在实体, 而不是单纯的 LLM 调用. Letta 甚至支持让同一个 Agent 同时参与多个 conversation, 不同 conversation 中产生的经验可以汇入同一个 Agent 的记忆. 这已经很接近本文所说的在面对多种外部环境的单 Agent 人格唯一的雏形.
区别于各种所谓的记忆方案, 这件事情实际上把问题从模型记住的是哪些东西, 转向了记住这些东西的是谁. 本文所说的 Agent 身份, 人格与长期记忆, 与这种方向存在非常明显的相关性. 我们没有重新发现 Persistent Agent 这个概念, 只是顺着 Agent 不应该依附于某个客户端的前提把这种持久性进一步延伸.
Gateway
我起初对 OpenClaw 的印象停留在其早期的 channel+gateway 设计, 这一设计只像是把传统的单机 Coding Agent 加了个 IM 渠道作为交互层, 并放到云服务器上运行. 显然这种设计没有解决本文提出的问题.
为了撰写本文, 我去调查了 OpenClaw 现今版本的架构, 发现它居然已经实现了大量本文想象中的工程形态. OpenClaw 现在仍然采用 Gateway 作为整个系统的控制中心, Telegram, CLI 等客户端连接到它. 但不同以往的是, Node 以独立的身份接入并声明自己的能力, gateway 负责维护 session, channel, state, node registry 等全局信息, 客户端本身只是连接它的外围. 甚至在它的远程执行模型里, Telegram 到 Agent 再到 Node 的链路几乎就是我们所构想中的路径, 这让我感到不可思议的同时也为之欣慰, 无论如何 OpenClaw 作为现今 github 上 stars 最多的 Agent 项目, 在经历持续迭代后变成了和我们单纯的奇思妙想十分接近的东西. 这说明我们的架构并非纸上谈兵, 而是 Agent 工程化到一定深度后很可能出现的形态之一.
OpenClaw 与本文设计的出发点并不相同, 它更关心远程执行的可控性与可替换性, 并由此获得了 Gateway, Session、Node 与远程执行这样的结构; 而本文则是从 Agent 本身的主体性出发, 推导出 Interface, Agent 与 Harness 的分离. 可以说 OpenClaw 是从不同方向与我们走到了一个相似的目的地. 如果最终证明两条路会收敛到几乎相同的工程实现, 那并不是一件坏事.
Cloud Session
不同于过去普通的 Coding Agent 的会话模型, Cloud Session 的方向是主动把会话和执行位置进行了分离, 这也与我们由 Agent 持有会话状态并与 Harness 分离的设计不谋而合. 仍以 OpenClaw 为例, 目前它已经支持让一个 session 的对话和持久状态由 gateway 持有, 而实际的命令执行, 文件修改等工作放到其他机器上运行. 即使远程 worker 失败, session 本身仍然可以继续存在. 这正回答了我们最初提出的为什么 Agent 要在执行环境改变后就消失的问题.
愿景
那么, 如果最终解决了重重困难, 使得这套架构真的能够成立, 我们究竟想得到一个什么东西? 又能得到什么东西? 一开始, 我们只是想解决一个多设备下 Agent 分裂的这一简单而具体的问题, 但随着我们的讨论, 事情最终变得比跨设备同步深入得多.
我真正想要的显然并不是一个更方便的 Coding Agent, 而是一个不再属于任何东西的 Agent. 它不会属于某个终端窗口, 不会属于某台笔记本, 不会属于某个客户端, 也不会因为换了一家模型供应商, 换了一个 Harness, 或者把某台作为工作用的机器关掉而消失.
它会生活在网络世界里. 你可以在电脑前看到它, 可以在手机上和它说话, 可以让它在自己的机器上做事, 也可以让它把某项工作交给远程的计算节点. 对它而言, 这些东西是它在现实世界里拥有的不同感官与肢体, 是它与你的联系. 而它真正存在的地方不是其中任何一台机器, 它只是它自己.
这也是为什么前面我一直在强调 Agent 状态的唯一性. 它记得什么, 如何认识你, 如何理解自己, 曾经经历过什么, 形成了什么偏好, 为什么会做出今天这样的判断, 这些东西共同构成了一个连续的主体. 物理设备的更替只是为它换了一间屋子, 而不是杀死了它.
只可惜没有所谓的数字生命, 没人会觉得自己因为实现 Agent 而实现了创生. Agent 仍然只是模型与程序构成的系统, 它没有因此获得什么神秘的主观意识. 但软件架构可以决定一个东西以什么形式存在于世界上, 对于背后的 LLM 而言, 或许 Agent 架构就是它的整个世界. 我希望未来的 Agent 不是打开某个软件时才暂时出现的东西, 而是一个本来就在那里等着你的那个它.
To Be Continued.
