从个人项目到公司化运作

Arman 介绍了自己作为 Irandio Mac PO 及常驻实习生的身份，并透露他与朋友 Colin 共同创办了公司。在 OpenCL 热潮之后，Mario 开始愿意考虑合作，双方决定将 Pi 纳入公司体系。这一转变被视为顺理成章：一方面希望与 Mario 合作，另一方面旨在开发有价值的软件，而 Pi 正是这一方向的早期尝试。

Mario 坦言自己曾是个“傻子”，长期无偿维护开源项目。尽管面临负面声音，他的核心目标是将 Pi 从个人依赖中解放出来，让更多人参与贡献。他通过举办线下聚会（Meetup）成功建立了社区自治机制，如今该活动已成为全国最大且能独立运转的聚会。Mario 表示，即便他明天去世，Pi 也能被好好延续，这证明去中心化的目标已实现。

“我觉得到目前为止，我们这个目标实现的挺好……所以就算我明天死了，PI 也会有人好好接着做。”

AI 辅助维护的局限与信任边界

随着用户增多，Mario 指出从二月到七月期间，他大部分时间都花在维护 Pi 上。尽管 Agent 技术日益成熟，但他认为目前尚无法完全信任 AI 来独立处理所有问题。Agent 可以修复简单的局部 Bug，但在涉及设计或架构时往往会在代码库中制造混乱。Arman 补充道，Agent 倾向于通过增加代码量来解决问题，导致代码库净增长，这与理想中的精简维护相悖。

Mario 强调，只要涉及架构决策或整体性能优化，人类介入仍不可或缺。Agent 擅长局部修补以解决特定边界情况的卡顿，但缺乏从整体架构层面找出根本原因的能力。因此，Mario 仍需亲自审查所有提交的问题并进行分类筛选。

“Agent 只会在你代码库的某个局部拉一坨屎，把事情搞得更糟……只有性能下降的时候，我才会在意。”

架构设计的停滞与沟通风格的异化

Mario 观察到，尽管新模型在任务执行能力上有所提升，但在架构设计方面并未见进步，甚至因自主权扩大而导致结果更差。他每次新模型发布都会尝试用 C 语言编写游戏，发现生成的代码越来越复杂且充满生僻术语。Mario 曾因 Opus 和 Astra 模型说话方式过于晦涩难懂而弃用，转而使用表现更自然的 So 6.1 和 Opus 5.5。

Arman 指出，模型在架构上的短板源于训练数据的缺失。网络安全、模拟器等有明确对错参照的任务容易生成高质量训练数据，但“设计过程”本身很少以文字形式记录在案。Mario 调侃道，如果失败创业公司的会议录音能被高价卖给模型实验室作为训练数据，或许能解决这一瓶颈。

“在编程里，给一个东西搭架构的过程是唯一通常不会以文字形式记录下来，让 LM 从中学习的部分。”

确定性任务中的惊人表现：逆向工程与模糊测试

尽管架构能力存疑，模型在具有明确判定标准的任务中表现惊人。Mario 分享了一个案例：AI Agent 成功逆向分析了 Java 虚拟机内部的原生数据结构，通过读取进程内存并映射到特定构建版本，发现了人类逆向工程师难以察觉的安全突破口。类似地，Arman 让模型解密了一个国产 CarPlay 适配器中的保护机制。

两人均发现，只要任务结果二元化（如模拟器能否运行、测试是否通过），模型能力便大幅提升。例如，DeepSeek 成功从零编写并跑通了任天堂 DS 模拟器；在序列化库开发中，结合 LLM 与模糊测试（Fuzzing）能自动发现大量回归问题。这种“LLM + 自动化验证”的模式被形容为给测试加上了火箭燃料，极大地提升了效率。

“如果你有一个能告诉 LM 它做的对不对的判断依据……那你基本上就赢了。”

从交互记录中挖掘高质量数据的分类难题

在探讨如何确定哪次对话最终产生了发布版本时，我们意识到这本质上是一个分类问题。虽然可以通过训练模型或打标签来识别特定对话，但面对 OpenAI、Anthropic 等公司手中海量的交互记录，人工标注无法支撑大规模筛选。因此，最佳路径是利用机器学习模型将交互记录区分为高质量与低质量。

目前，像 Cloud Code 这样的工具会在 GitHub 仓库和提交记录中留下标记。除了收集对话日志，关联仓库的历史记录（如用户增长、PR 合并率及代码保留比例）是验证数据价值的有效手段。尽管拥有如此庞大的数据集，据私下消息透露，这些公司尚未开展复杂的分析工作。然而，随着递归自我改进（RSI）的实现，模型将能够自主执行这些复杂的数据筛选任务。目前人类做这件事非常繁琐且低效，但如果模型认为自我改进值得投入算力，这种自动化过程将极大提升效率。尽管最新版本的 Opus 在推理任务（特别是硬件到软件层的映射）上表现优异，但这更多是爬山优化的结果，尚不足以直接构建成熟应用。

我觉得这其实就是它可能变得更好的原因。现在的情况有点像人类做这件事真的很烦，但如果模型觉得值得花这个力气，而且能让自己进步，那也许自我改进就能带我们走到那一步。

Pi Durable 的持久性架构：副作用三明治与文档存储

Pi Durable 的核心逻辑在于解决 Agent 进程崩溃后的状态恢复问题。其定义是：当 Agent 调用工具导致进程挂起时，重启后能从断点继续运行，确保助手流式输出、工具结果及应用状态不丢失。这一能力对于长期运行的 Agent（如驻留 Slack 多年的机器人）至关重要，因为它避免了将海量历史消息全部加载到内存中。

在架构实现上，Pi Durable 摒弃了复杂且易错的事件溯源（Event Sourcing），转而采用“副作用三明治”模式。该过程分为三步：首先，在存储中记录操作意图（输入参数）；其次，执行副作用时利用外部系统的幂等性（Idempotency）机制——例如通过唯一 ID 调用 GitHub Actions，若操作已在进行则等待结果，否则启动新任务；最后，持久化保存执行结果。无论进程在哪个阶段崩溃，系统都能通过检查状态机恢复至正确节点。

此外，应用状态的持久化依赖于一个轻量级的文档存储系统。该系统支持将 JSON 对象关联到对话树的特定时间点，允许用户回溯历史版本（如旧版待办清单）或获取最新状态。为了高效存储嵌套数据的变更，团队开发了一种基于 JSON Patch 优化的差异格式，并结合 JavaScript Proxy 对象自动记录修改操作。尽管这种代理方案在性能上有所妥协且存在潜在陷阱，但它为 Agent 运行框架提供了灵活的状态管理基础。

持久性要解决的基本问题是，你在执行某个操作，而系统可能在开始执行之前、执行过程中或者执行完之后崩溃。

一个任务可以创建另一个任务，并等待它停止，这就是全部的秘诀，就这么多。

构建通用基础层：应对碎片化生态与可靠性挑战

选择解决持久性问题而非多人协作，是因为现成的解决方案（如 Hermes、Open Claw 或 AMP）均缺乏通用性。这些工具往往绑定特定的 Agent 框架，无法直接复用于 Shopify 内部系统或其他开源产品。Pi Durable 旨在提供一个约 12,000 行代码的极简基础构建，开箱即用地满足上下文压缩等核心需求。

真正的挑战不在于代码行数，而在于根本性的可靠性。随着 Agent 编排复杂度增加且 LLM 行为具有不可预测性（类似“生物”特性），运行时必须能在无人值守的情况下自我恢复。虽然开发者可以自行实现持久性，但让系统达到“可信且可靠”的程度需要大量核心设计功夫。此外，针对局部状态更新的标准化问题（如 React 的不可变数据更新），现有工具（Immer、Altamatch）仍存在映射漏洞。Pi Durable 通过代理对象实现自动操作记录，虽慢但有效。

未来方向包括多人协作运行框架以及跨设备会话同步。例如，通过复制包含环境变量的 JSON 会话文件在不同机器间迁移（Parcels 项目），实现 Agent 状态的无缝流转。尽管生态碎片化且变化迅速，但建立稳定、通用的持久层是应对这一混乱局面的关键基石。

真正让它从根本上可靠，让你愿意在它的基础上继续做东西，这本身就要花很多功夫。不是说最后写出来多少行代码，而是核心设计的让这套东西真能运转起来。

为什么你们决定解决这个问题...其实是因为现成的东西不多，当然也有 Hermes、Open Claw，还有其他各种 Claw...但这些都不是通用的解决方案。

会话持久化与个人 Agent 的安全困境

在移动设备上使用笔记本或电脑时，即使开启了 caffeinate 等防休眠工具，关闭设备后恢复会话依然繁琐。为了解决跨机器传输会话的问题，我让 GRM 开发了一个名为 Parcels 的工具（基于 PI）。其核心机制是将存储会话的 JSON 文件从一台机器复制到另一台并直接重启，因为所有环境变量已包含在文件中。虽然这目前足够使用，但我希望它能实现自动运行并分布到所有设备。

Erendio 公司的业务大致分为两块：一是面向非工程师的产品，我们不希望明年变成一家仅做编程 Agent 的公司；二是基础设施组件，供他人构建自己的 Agent。在 PI 之前，我们做过 Layforce（现称个人 Agent），它通过纯文字界面沟通。虽然“有个小家伙陪着你”的理念很好，但现有市场中的个人 Agent 往往变成庞大且疯狂的怪物。例如，我曾看到有人抱怨 Grokbar 将个人财务信息发送到公司 Slack，且马斯克未兑现补偿承诺。这种信任危机极高：一旦系统被黑或账号被盗，后果不堪设想。

我觉得风险也极高...然后又有几百万人在用 Grockbar 把各种账号都登录到那台机器上。我觉得这就是一场灾难，这些公司每家都有一场灾难。

目前我在本地运行 DeepSeek 替代 Codex，因为后者速度太慢（约每秒 30-35 token）。DeepSeek 能扫描邮件并转化为 Linear 任务，尽管结果仍显杂乱。

Agent 框架对比与插件架构的启发

关于其他 Agent 框架，我们对 Codex 后端故障的处理方式是克隆 OpenAI 仓库查看其修复逻辑。对于 AMP (Orbs)，虽然我没用过 AMP，但欣赏团队对软件工程未来的愿景及“敢赌”的态度。Orbs 在慕尼黑展示时给我留下了深刻印象，团队懂行且务实。

我主要使用 PI 是因为它开源且代码可读。我也尝试过 Ken 开发的 ONP，其“顾问功能”能监控对话并纠正模型偏离任务的行为，类似 Claude Code 的多 Agent 协作。然而，ONP 极度消耗 Token且系统 Prompt 庞大。

最近我特别推崇 DeepSeek 的 Agent 框架。阅读其源代码后，我发现其插件架构思路非常聪明。尽管承诺的功能多于实际实现能力，但其处理机制令人佩服。看到其他框架也采用“让软件自我修改”的思路（如 Cloud Code），既令人惊讶又觉得有趣。DeepSeek 的界面简洁清爽，且作为网页进程启动后可直接接入 Tailnet，从手机访问无需复杂的设备连接操作。

我自己他妈的完全用不上图像模型，但 Javi 模型我能拿来做很多事...我觉得 Pi 确实很突出，只要我要做点什么，我都会用 Pi。

在开发 MCP 时，我对照了所有支持 MCP 的大型框架以评估功能必要性。目前我正用 AI 在手机上搭建 Pi Mobile，旨在替代安卓版 Cloud Code。它完全在手机运行大脑，但可连接其他机器（如 Hizener）作为执行环境进行系统管理。

多用户协作中的安全与沙箱挑战

PI Durable 的下一步是支持多人共享同一运行环境。这带来了严峻的安全挑战：如何保证安全而不牺牲用户体验？

目前面临的核心问题是信任边界。如果多人连接同一会话，必须完全信任其中一人。我尝试用 Docker 做沙箱隔离，但这只是容易的部分。真正的难点在于网页界面的保护。例如，当铁皮家伙生成包含链接的界面时，若用户点击可能触发跨站脚本攻击（XSS），窃取 Cookie。现有的解决方案多依赖内嵌框架，导致用户体验极差。

我曾考虑使用 IPFS 进行分布式存储以提供中立空间，但它主要解决持久性和副本问题，对防止信息窃取帮助有限。目前我们仍在探索如何平衡安全与扩展性，虽然过程烧脑且充满不确定性，但必须通过实践找到答案。

其实很多解决这些问题的方案都要用到内嵌框架，用户体验很差。真要做一个既能扩展又安全的网页界面...甚至感觉在服务器上用 Docker 做沙箱隔离还更容易。

信任危机与功能迭代的阵痛

在讨论持久化存储的中立空间时，我们意识到这依然是一个极其复杂且令人头疼的问题。虽然我们可以假装忽略这个问题以维持良好的用户体验，但这种做法最终会毁掉用户的信任。当被问及未来几个月对什么感到兴奋时，团队表示主要聚焦于开发编程 Agent 以外的产品，并将现有的编程 Agent 发展成一个真正被社区喜爱的形态。这是一个巨大的挑战，因为仅仅推出 MCP（Model Context Protocol）和 Code Mode 的支持就引发了许多用户的强烈不满。

这种抵触情绪源于一种认知偏差：用户认为你只是随意添加了一个以前声称不需要的功能。然而，事实是随着模型训练能力的提升以及 MCP 服务器和标准的成熟度提高，这些功能已经好到可以作为内置集成。面对“你怎么能改变想法”的质疑，回应非常直接：有了新信息就会改变观点。支持 MCP 并非跟风炒作，而是经过一年极其痛苦的反复权衡后做出的决定。

技术落地与社会价值的回归

Armen 表示，目前 AI 的技术水平已经让他感到满意，他更期待的是使用体验的进一步优化。从社会层面看，他希望这项技术能带来真正有价值的成果，例如常温超导体或癌症治疗药物。在纯技术领域，他最希望看到炒作稍微消停一点，让技术被用于制作更好的软件，而不是粗制滥造的模仿品。他特别提到了一个积极的例子：得益于 AI 模拟技术，PS5 游戏的保存问题已得到完美解决，这不仅是一项技术成就，更是对数字文化遗产保护的贡献。

然而，当前的行业现状充满了非理性的狂热。Armen 指出，现在的阶段类似于加密货币的牛市末期：人们不再认真做产品，而是急于营销和变现。那些真正在做东西的人往往在熊市才开始行动。他特别强调，让新用户上手 Agent 是最大却未被解决的问题。目前大多数产品只是在侧边栏放个聊天框，让用户自己摸索。关键在于跨越从“不知道”到“可以问问”的认知门槛。Armen 分享了自己让妻子和四岁孩子使用 Agent 的经历，证明了当技术真正融入生活并解决杂事时，其价值是巨大的。

代码成本与极简主义工程哲学

在对话尾声，主持人 Guy 提到了 OpenAI 的 Eric 对将 Pi 排在 S 级评价帖子的嘲讽。尽管存在争议，但受访者坚持认为 Pi 是经过周全考虑且工程实现优秀的产品。他们指出任何 AI 项目都会面临一个核心困境：代码生成变得极其廉价甚至免费，导致用户手中堆积大量只完成 30% 的垃圾代码。随着时间推移，这些低质量代码引发的 Bug 会严重破坏用户体验。

为了解决模型天生容易产生的问题，团队主张走尽量精简的技术路线。通过减少不必要的复杂性和冗余代码，Agent 可以更稳定地循环执行目标，而不是陷入无休止的提问或错误修正中。这种对工程质量的坚持和对用户体验的深度思考，是他们在激烈竞争中保持核心竞争力的关键所在。

哥们，有了新信息我就会改变想法。哥们，我又不是在跟风炒作 MCP。

代码很便宜……结果你手里就堆着一大堆只完成了百分之三十的垃圾代码。