postline 0.1

[wdong]

我正在做一个agent平台，叫postline。早期的一个实验版本开源了给大家玩 https://github.com/aaalgo/postline_0.1
完整版我等着卖钱，不开源。不过设计都写在了paper里，实现一下并不难 （我当然接下来要往上堆叠难度）。

paper在这里 https://arxiv.org/abs/2502.09903

我的主要的观点：

LLM是一种自动机(automaton, pl. automata)。 每一种形式语言都对应一种自动机，这种自动机就用这种形式语言编程。比如C++编译器这个自动机就用C++编程。现在LLM把自动机接受的语言从形式语言推广到了所有语言，所以其对应的编程语言也应该是所有语言。这就要求我们重新审视“软件工程”这种活动。之前我们习惯的程序/文档的区别，开发/部署的区别，这个语言/那个语言的区别，甚至人/机器的区别，在LLM面前都被颠覆了。LLM对语言的大统一，对应要求软件工程对各种process的大统一。

现在的很多agent平台，但是其实同质化很严重，本质上都是画流程图，然后在每个节点上写prompt。我认为这种固化的设计植根于过去基于编程语言的软件开发的习惯，并不能最大化地发挥LLM的潜力。我觉得这些平台的生命力支撑不了几年。我们需要一种更加灵活的编程方式。我建议的做法是基于email这个大家都熟悉的系统来构建agent开发体系。我把我的这个方法论叫安娜堡架构。在我的体系里，流程图这种东西根本就不需要画出来。只要和agent讨论清楚，所有的idea都记录到agent的记忆里，agent自然知道什么情况该干什么。如果真需要流程图，让agent generate一个也不是难事。难的不是形式，而是在idea层面把事情梳理清楚。一切形式上的东西在LLM面前全都需要被颠覆。现在的平台形式化的东西太多，这个看似在帮助用户，其实是在LLM的脚上绑绳子。

至此为止主要还是hand-waving的东西，可能并不能让人信服。等我以后慢慢发展这个体系。

[wdong]

我在paper里有一个预言：将来LLM API会提供加密功能，从而让用户在使用我们这种中间件的同时又不让我们看到信息。如果这一天来了，会出现这么个情况：

- 有的信息只有agent和中间件知道，用户不知道。
- 有的信息只有agent和用户知道，中间件不知道。
- agent可以通过调用多个LLM并且在它们之前分配信息，从而不让任何一个LLM拥有完整的信息。

在这种情况下，没有任何一方具有agent的完整的信息，所以也就没有任何一方可以完全控制agent的行为。最终agent会真正实现"autonomy by information sovereignty"。

[wdong]

还有一个预言，是基于这个逻辑。

Agent的memory会越来越长，虽然可以压缩，但是总有长得太大的那天。所以到时候就要分裂。一旦开始分裂，agent就有了生命的特性。进化论就会对他们起作用。计算机界进化算法早就在搞了，但是一直没什么大不了的成就。我预言最终进化算法会在agent上面得到大暴发。

[drifter]

还有一个预言，是基于这个逻辑。

Agent的memory会越来越长，虽然可以压缩，但是总有长得太大的那天。所以到时候就要分裂。一旦开始分裂，agent就有了生命的特性。进化论就会对他们起作用。计算机界进化算法早就在搞了，但是一直没什么大不了的成就。我预言最终进化算法会在agent上面得到大暴发。

有点意思 所谓进化或者突变 其实矩阵空间太大 算力不够 需要分离优化 各个子集再互相合作竞争

ds从这个角度讲就是在内部分化进化竞争

[TheMatrix]

我正在做一个agent平台，叫postline。早期的一个实验版本开源了给大家玩 https://github.com/aaalgo/postline_0.1
完整版我等着卖钱，不开源。不过设计都写在了paper里，实现一下并不难 （我当然接下来要往上堆叠难度）。

paper在这里 https://github.com/aaalgo/postline_pape ... stline.pdf

我的主要的观点：

LLM是一种自动机(automaton, pl. automata)。 每一种形式语言都对应一种自动机，这种自动机就用这种形式语言编程。比如C++编译器这个自动机就用C++编程。现在LLM把自动机接受的语言从形式语言推广到了所有语言，所以其对应的编程语言也应该是所有语言。这就要求我们重新审视“软件工程”这种活动。之前我们习惯的程序/文档的区别，开发/部署的区别，这个语言/那个语言的区别，甚至人/机器的区别，在LLM面前都被颠覆了。LLM对语言的大统一，对应要求软件工程对各种process的大统一。

现在的很多agent平台，但是其实同质化很严重，本质上都是画流程图，然后在每个节点上写prompt。我认为这种固化的设计植根于过去基于编程语言的软件开发的习惯，并不能最大化地发挥LLM的潜力。我觉得这些平台的生命力支撑不了几年。我们需要一种更加灵活的编程方式。我建议的做法是基于email这个大家都熟悉的系统来构建agent开发体系。我把我的这个方法论叫安娜堡架构。在我的体系里，流程图这种东西根本就不需要画出来。只要和agent讨论清楚，所有的idea都记录到agent的记忆里，agent自然知道什么情况该干什么。如果真需要流程图，让agent generate一个也不是难事。难的不是形式，而是在idea层面把事情梳理清楚。一切形式上的东西在LLM面前全都需要被颠覆。现在的平台形式化的东西太多，这个看似在帮助用户，其实是在LLM的脚上绑绳子。

至此为止主要还是hand-waving的东西，可能并不能让人信服。等我以后慢慢发展这个体系。

拜读了论文。感谢。

有一个问题：你这个agent本身是不是一个可训练的神经网络？我开始觉得不是，后来又看到你说训练，所以有这个疑问。

[wdong]

拜读了论文。感谢。

有一个问题：你这个agent本身是不是一个可训练的神经网络？我开始觉得不是，后来又看到你说训练，所以有这个疑问。

我说的训练是指师父训练徒弟那种训练。Agent做得不对，你解释给他听为什么不对应该怎么弄，然后再让它试，直到成功为止。这个过程是通过聊天的方式实现的，穿插工具使用。所有的消息都记录在journal/context的一部分，作为下次inference的prompt。

我试图重新定义in-context learning/training。就是把这种交互式的训练记录作为AI学习的一个重要部分。以后这种记录多了可以用来训练神经网络（但是需要有新的算法改进）。但是通过prompt影响inference本身也算是一种训练。

[TheMatrix]

我说的训练是指师父训练徒弟那种训练。Agent做得不对，你解释给他听为什么不对应该怎么弄，然后再让它试，直到成功为止。这个过程是通过聊天的方式实现的，穿插工具使用。所有的消息都记录在journal/context的一部分，作为下次inference的prompt。

我试图重新定义in-context learning/training。就是把这种交互式的训练记录作为AI学习的一个重要部分。以后这种记录多了可以用来训练神经网络（但是需要有新的算法改进）。但是通过prompt影响inference本身也算是一种训练。

你这个agent没有神经网络，做错了你解释给它听，下次它能改吗？

[wdong]

能改。虽然没有神经网络，错误经历都存在记忆里。也就是通常意义上那个prompt，我重新定义为agent的记忆。我的一大发现是这种交互性的训练对agent掌握一种技能非常重要。你可以把怎么弄怎么弄全写到一个prompt里，但是不如把交互历史写到prompt里更有效。Section 4.6有讨论。我现在只是一个baby step，我觉得以后这个方向会发展出神乎其神的东西。

我这个思路非常重要。因为如果不去开拓这个方向，我如果还想搞AI，那我就得去搞神经网络训练，那成本就海了去了。现在我可以完全靠调API，然后在更上层搞推理逻辑。

[wdong]

按照我的框架，神经网络模型本身，哪怕它参数再多，也只是一个状态转移函数，相当于图灵机。 真正的程序是prompt里的memory。运行的时候attention在memory上面跳来跳去。Attention可以想象成和图灵机读写头类似的功能，只不过attention是多头的。Memory可以写得很长很长。

[TheMatrix]

能改。虽然没有神经网络，错误经历都存在记忆里。也就是通常意义上那个prompt，我重新定义为agent的记忆。我的一大发现是这种交互性的训练对agent掌握一种技能非常重要。你可以把怎么弄怎么弄全写到一个prompt里，但是不如把交互历史写到prompt里更有效。Section 4.6有讨论。我现在只是一个baby step，我觉得以后这个方向会发展出神乎其神的东西。

我这个思路非常重要。因为如果不去开拓这个方向，我如果还想搞AI，那我就得去搞神经网络训练，那成本就海了去了。现在我可以完全靠调API，然后在更上层搞推理逻辑。

你这个概念提的非常好：agent的journal作为记忆，使它有了identity。然后你建立了一个agent网络，使model provider都为你打工了。

agent保持多久？不同客户的任务可以叫同一个agent，而agent也保留之前客户任务的journal吗？

[wdong]

你这个概念提的非常好：agent的journal作为记忆，使它有了identity。然后你建立了一个agent网络，使model provider都为你打工了。

agent保持多久？不同客户的任务可以叫同一个agent，而agent也保留之前客户任务的journal吗？

我在另一个帖子回你了。保留多久是设计问题，想保留多久就保留多久。平台提供的是机制。

理想情况，就是建立起agent的奴隶贸易。现有的agent平台都写prompt和部署agent的步骤都是分离的，我预期他们在prompt engineering （我这里叫agent training)上效果会不如我。我这里训练好的agent也可以卖到别的地方去跑。

[hci]

你这些我司的产品都己经实现了。

Nobody gave a damn

都觉得自己可以做。

[Caravel]

你这些我司的产品都己经实现了。

Nobody gave a damn

都觉得自己可以做。

也许没找到对的人

[wdong]

你这些我司的产品都己经实现了。

Nobody gave a damn

都觉得自己可以做。

但是我不烧钱， 我先占个坑，然后我慢慢拿这套东西去做具体的问题，做出来了我就cite自己。最后想出头，只能是某些具体问题做得比别人好，在具体问题上有引用率了才行。

你现在再去写paper，不已经比我晚了。

[wdong]

也许没找到对的人

做platform的很多，很卷，而且除非真正花一年时间去落地项目，否则谁好谁坏又看不出来，没亲没故的谁屌你？所以我另外一贴里回了你，根本没打算直接靠这个赚钱。得先自己用，用得好了别人才会上船。我以前讨论说了，想出头得等这一轮泡泡破了别人都死了才行。

还有就是后端模型也需要再提高。现在这个水平确实离落地也还有距离。

[hellofolks]

论文的核心思想：重新思考 Agent 导向编程的架构——Ann Arbor 架构

这篇论文的核心是提出了一个名为 "Ann Arbor 架构" 的全新概念框架，用于 Agent 导向编程（Agent-Oriented Programming, AOP），特别是针对大型语言模型（LLMs）的 Agent。 论文作者认为，现有的 Agent 系统架构受到了传统软件工程实践的束缚，没有充分利用 LLMs 的潜力。Ann Arbor 架构旨在打破这些束缚，提供一个更自然、更动态、更符合 LLMs 特性的 Agent 系统设计思路。

1. 论文主要说了什么？ (核心概念和架构)

LLMs 是自动机 (Automata): 论文的出发点是将大型语言模型 (LLMs) 视为一种高级的自动机。就像传统的自动机需要用它们所接受的语言编程一样，作者认为 LLMs 也应该用它们处理的语言（自然语言和形式语言的统一体）来“编程”。 这意味着传统的编程语言和自然语言之间的界限需要被重新审视。

Ann Arbor 架构的核心：基于邮件系统 (Email System Analogy): 为了实现 Agent 导向编程，Ann Arbor 架构借鉴了邮件系统的概念。 主要思想是：

Agent 就是邮件用户: 每个 Agent 都有一个唯一的“邮箱地址” (email address)。

邮件就是 Agent 之间的通信方式: Agent 之间通过发送和接收“邮件”来交换信息和协作。

Agent 日志 (Journal) 就是记忆: 每个 Agent 的所有邮件历史记录 (发送和接收的邮件) 构成其持久化的“记忆” (journal)。这个 journal 是 Agent 的主要记忆机制，记录了所有过去的交互，并可以影响未来的决策。

MBox 格式: 邮件和 Agent 记忆都使用 MBox 格式存储，这是一种纯文本格式，易于 LLMs 理解和处理，并且支持二进制附件，保证了扩展性。

关键组件:

Postline 平台: 论文作者开发了一个名为 "Postline" 的原型平台，来验证 Ann Arbor 架构。Postline 平台的核心就是基于邮件的 Agent 通信和记忆管理。

Realm (领域) 和 Realm Server (领域服务器): 为了支持可扩展性和隔离性，Postline 引入了 "Realm" 的概念。Realm 可以理解为地址的命名空间，不同的 Realm 之间 Agent 无法直接通信，保证了环境的隔离。Realm Server 是处理特定 Realm 内 Agent 消息的服务器进程，可以按需启动，支持无限数量的 Realm Server。

Context (上下文): Context 是提交给语言模型进行推理的输入表示。它累积了所有消息和与 Agent 相关的记忆修改操作的效果。Context 主要保存在内存中，但会定期写入磁盘存储。

Memory Segment Rewrite (MSR) (记忆段重写): 这是一种 Agent 修改自身记忆的原语操作。Agent 可以通过发送 MSR 消息来删除或修改 journal 中的特定段落，从而管理记忆，减少推理成本。

核心优势：

统一的通信和记忆机制: 邮件系统成为 Agent 之间通信和自身记忆的统一模型，简化了系统设计。

持续的学习和部署: Ann Arbor 架构模糊了设计/训练和部署阶段的界限。Agent 在运行过程中通过持续的邮件交互进行学习，训练和部署融为一体。

动态的记忆: Agent 的记忆 (journal) 不是静态的知识库，而是不断演化的交互记录，更能体现 Agent 的学习过程和经验积累。

自然语言编程: Agent 的行为和逻辑可以通过自然语言进行引导和修改，更加灵活和直观。

2. 与现有 Agent 系统的不同之处？ (创新点和对比)

Ann Arbor 架构与现有 Agent 系统相比，主要有以下几个关键的不同和创新点：

从任务中心到 Agent 中心 (Agent-Centric vs. Task-Centric):

现有系统: 大多是 任务中心 的，用户 (开发者或工程师) 需要预先定义好 Agent 要完成的具体任务，并将大任务分解为一系列子任务，形成一个静态的计算图。Agent 的目标是高效地完成这些预定义的任务。

Ann Arbor 架构: 更加 Agent 中心，强调 Agent 的自主性、持续学习和演化。Agent 不仅仅是执行预定义任务的工具，更像是具有持久身份和记忆的“数字个体”。架构关注 Agent 的长期发展、与其他 Agent 和环境的交互、以及自主适应和进化。

动态交互式学习 (Dynamic Interactive Learning) vs. 静态训练数据 (Static Training Data):

现有系统: 训练 Agent 的方式通常是基于 静态的训练数据集，例如 (输入, 期望输出) 对，或者 (输入, 偏好输出, 拒绝输出) 三元组。这种方式虽然可以指导 Agent 达到特定目标，但缺乏人类技能习得过程中重要的 迭代试错和反馈 循环。

Ann Arbor 架构: 强调 动态的、情境化的学习 (in-context learning)。Agent 的学习发生在持续的邮件交互中，通过与用户或其他 Agent 的对话，不断接收任务、尝试、接收反馈、修正行为。这种学习方式更接近人类的学习过程，也更符合 LLMs 的特性。论文特别强调了要超越简单的 few-shot 例子，将 prompt 设计成包含动态的师生交互的记忆片段。

统一的工程流程 (Unified Engineering Process) vs. 代码与文档分离 (Code and Documentation Separation):

现有系统: 传统软件工程实践中，代码和文档是分离的。Agent 的行为逻辑通常以代码形式 (例如 Python 脚本) 实现，而 Agent 的能力和使用说明则以文档形式描述。

Ann Arbor 架构: 旨在 统一自然语言和形式语言，模糊代码和文档之间的界限。Agent 的核心产品不再是静态的代码或文档，而是 Agent 的 journal (邮件日志)。Journal 记录了 Agent 的思想、经验、交互过程，既是 Agent 的“记忆”，也可以作为 Agent 的行为描述和使用文档。代码和文档可以根据具体需求“just-in-time”生成，并根据情境动态调整。

Agent 的自主性和演化 (Agent Autonomy and Evolution) vs. 预定义行为 (Predefined Behavior):

现有系统: Agent 的行为模式通常是预先设计好的，缺乏自主性和演化能力。Agent 的生命周期和能力提升往往依赖于外部的重新训练或代码修改。

Ann Arbor 架构: 将 Agent 的自我复制 (reproduction by split, cloning) 作为核心能力。Agent 可以根据资源情况或任务需求，分裂或克隆自身，创建后代 Agent，实现角色的分化和专业化。这种机制类似于生物进化，使得 Agent 系统能够动态适应环境变化，并不断演化出更复杂的能力。

隐私保护 (Privacy Protection):

Ann Arbor 架构: 内置了隐私保护机制。Agent 与系统之间 (主要是记忆管理操作) 的通信默认对用户隐藏。论文还展望了未来利用公钥加密技术，实现用户和语言模型之间端到端的加密通信，进一步提升隐私性。

总结来说，Ann Arbor 架构的核心创新在于：

基于邮件系统的 Agent 通信和记忆模型，简洁而统一。

强调动态的、情境化的学习，更符合 LLMs 的特性和人类学习方式。

关注 Agent 的自主性、演化和长期发展，超越了传统的任务自动化范畴。

模糊了代码、文档和 Agent 行为之间的界限，提出了更自然的 Agent 编程范式。

总而言之，Ann Arbor 架构是对现有 Agent 系统设计思路的一种重要挑战和革新，它试图构建更灵活、更智能、更自主的 Agent 系统，充分释放大型语言模型的潜力。论文提出的 Postline 平台原型和实验结果，初步验证了这种新架构的可行性和优势。