PS：最近从 Qoder 离职了。原本还想继续折腾 AI Coding 和 Coding Agent 相关的开源项目，但考虑到过去的工作经历， 还是希望换个应用方向，尽量避开与此前工作内容、产品方向的交集，做点不一样的东西。

于是，就有了这个新坑：Pero。

GitHub：https://github.com/phodal/pero

好久没有认真开一个不一样的新坑了。过去几年，我的大部分精力都放在 AI Coding、Coding Agent，以及 AI 如何改变软件工程上。 从 AI 辅助编程，到 Agent 自主执行、多 Agent 协作，再到各种工程化实践，基本上一直围绕着「如何让 AI 更好地帮助开发者」 这个问题打转。

虽然想换个方向，但过去积累的技术和经验总还是有些舍不得放下。毕竟，Agent 的任务规划、工具调用、长期记忆、多 Agent 协作、 执行环境管理等能力，并不只是为软件开发准备的。

这一次，我想把这些积累带到科研工作流中。

为什么是 AI for Science（AI4S）？

最近一直在想一个问题：

如果 AI Agent 不只是帮助开发者写代码，而是能够参与科研任务、组织研究过程、调用专业工具，甚至协调分布式计算环境， 那么我们能把它带到哪里？

科研工作流往往从一个 Python 脚本、Notebook 或模型 Demo 开始。随着研究深入，又会涉及文献、数据、实验、计算资源和结果验证。 这些环节和软件工程有不少相似之处，但也提出了不同的要求。代码能运行，并不意味着科研结论成立。输入数据来自哪里、 使用了什么方法和环境、结果能否复现，以及应该由谁来判断它是否可信，都是需要认真对待的问题。

Pero 是一个面向科研工作流的开源工作区，尝试把领域 App、Agent 和计算资源连接起来。 当前先从 Virtual Cell 入手， 探索如何把散落在脚本、Notebook 和专业工具中的研究过程，组织成可以持续执行、追踪和复核的项目。

这还是一个很早期的项目。很多想法需要通过真实场景来验证，也有不少技术问题尚未解决。比起一开始就覆盖所有科研领域， 我更希望先找到具体问题，把一条有用的工作流做出来。

Pero 想做什么？

最终形态还在探索，但目前有三个明确的切入点。

1. 以项目为中心的工作区

我更想探索的，是如何让 Agent 参与一个持续推进的研究项目，而不只是完成一次问答。

为此，我希望围绕 Project 组织研究问题、文献、数据、任务、实验结果与知识。 让 Agent 能够理解项目上下文，持续跟踪研究进展，并在数据或研究条件发生变化时，提出可供研究者审阅的新任务。

从一次性对话，走向持续的研究协作。这是 Pero 想探索的方向，完整的项目记录、长期记忆和主动工作流还需要逐步实现。

2. 开放式分布式 Agent 协作

科研往往需要不同专业的人和工具共同参与。我希望 Pero 能够支持不同的 Agent 在同一个项目中分工， 并把任务交给获准使用的本机、实验室服务器或云端计算资源。

过去参与开源主要是贡献代码，未来或许还可以贡献 Agent、Tokens、算力和实验结果。目前，Pero 已经有了 Task、Run、Worker 的基础实现，并开始支持 GitHub 任务导入、认领与分发。可以先从一个具体任务开始，探索如何把协作和执行连接起来。

任务广场：https://app.openpero.com/tasks （服务器有点拉了）

这距离完整的多 Agent 研究协作还有很长的路。自动化贡献、研究产物登记与独立验收等环节，仍需要继续完善。

3. 领域驱动的垂直场景

我希望不同的科研领域能够拥有自己的 App，把领域数据、专业工具、计算方法和 Agent 组合起来。比如：

• 生命科学中的细胞图谱、基因表达和蛋白质结构分析。
• 材料科学中的分子建模、晶体结构和物理仿真。

不同领域有不同的数据格式、计算模型和验证方法。一个通用聊天界面，很难直接承载这些差异。

所以，Pero 希望支持一种可组合的科研 App 模式：领域能力可以通过专门的界面独立使用，后续也能作为工具被 Agent 调用， 参与更复杂的研究工作流。

一个示例：从 Virtual Cell 开始

为了验证这个方向，我先做了一个具体的实验：Virtual Cell（虚拟细胞）。它最初来自一位前前同事提出的问题。我借助 ChatGPT 做了一些资料调研，并尝试把相关分析与可视化流程做成可交互的 App。我不是这个领域的专家，因此目前更适合把它看作工作流与交互方式的原型； 其中的科学假设、方法选择和结果解释，还需要领域研究者参与审查。

目前，它包含参考细胞图谱浏览、扰动分析流程、一阶反应模拟，以及三维体数据可视化。使用者可以通过界面查看细胞数据、 调整参数和观察输出，减少在不同脚本与工具之间切换的操作。 其中，反应模拟和体数据示例用于演示交互，不能代表经过科学验证的细胞预测模型。扰动分析也有其数据与评估范围，不能直接推广为对未知条件的可靠预测。

Virtual Cell 延续了此前在 Point 中公开的虚拟细胞实验，目前已经作为 Pero 的第一个领域 App 接入。本地界面与 Python 后端已经可以运行；Agent 工具调用、Task/Run 执行和 Project 产物登记，还没有与它连通。

不过，我觉得这里有一个很有意思的方向：如果 Virtual Cell 能成为一个 Agent 可以理解和操作的科研环境，会怎样？比如， 研究者提出一个基因扰动相关的问题，Agent 协助查阅文献、整理可选方法、提出实验计划。研究者确认后，再调用领域 App 或远程计算资源执行分析，将输入、方法版本、执行环境和结果保存到 Project 中，供后续复核与迭代。

这是一条希望逐步打通的工作流。相比一开始就设计一个宏大的 AI4S 平台，我更愿意从具体的领域 App 入手，边做边验证， 再沿着这个思路探索更多场景。

技术栈

围绕工作台、任务协调和领域计算，Pero 目前采用了几种不同的技术：

• Python：承载科学计算、数据处理与领域 App 后端，按具体场景接入方法和模型。
• Rust：承载 GPUI 工作台、本地 Host、ACP 接入与独立 Worker；当前桌面主路径采用 GPUI/Wasm，也在探索原生桌面形态。
• Go：承载云端任务协调与分发；自研 Agent Harness 是后续探索方向。
• Electron 与 JavaScript/TypeScript：承载桌面壳、领域 App、可视化及 Web 集成。

设计上，也参考了几个不同方向的探索：Zed 与 GPUI 的工作台和界面实现、Kiro Crew 的持久工作区与 App 组合、Claude Science 的科研工作台， 以及 DeepSeek Harness 的插件架构。

DSH 的 harness PR 在：https://github.com/phodal/pero/pull/4 如果你也有兴趣欢迎来设计。

目前，macOS 桌面开发版、ACP 会话、分布式任务基础以及 Virtual Cell 已经有初步实现。领域 App、Agent 和研究结果复核之间的完整流程，仍需要逐步打通。

小结

从 AI Coding 到 AI4S，对我来说，既是一次方向上的切换，也是一次重新学习。我希望通过开源的方式，和科研工作者、AI 研究者以及开发者一起，把这些想法放到真实问题中检验。

如果你有一个正在反复手工操作的科研流程，欢迎带着具体问题来聊：输入是什么、目前怎么做、最后怎样判断结果是否有用。也欢迎贡献领域 App、分析方法，或者帮助审查 Virtual Cell 中的方法与示例。

Pero 最终会变成什么样子，现在还很难说。这一次，不急着给出答案。先把坑挖起来，边做边探索，也欢迎更多人一起参与。

GitHub：phodal/pero