StarNet：你画的像素艺术空间站，就是 Agent 真正运行的工作流

来源：GitHub 仓库 androoAGI/starnet
日期：2026-09-26
仓库：https://github.com/androoAGI/starnet
Trending：日增 118 stars

一句话总结

StarNet 是一个本地优先的桌面 agent harness——你在像素艺术风格的空间站里放置房间、走廊、物件，你画的布局就是 agent 真正运行的工作流。不是模拟，不是可视化，是字面意义上的运行时。

场景开篇

你在桌面上打开一个像素风的空间站编辑器。画一个房间叫"工程部"，放两个 agent 桌位，给每个桌位挂一个"代码能力"徽章。画一条走廊连到"测试部"房间，走廊上标"代码交接"。在测试部放一个 agent，挂"测试能力"。

点"运行"。

工程部的 agent 开始写代码。写完的代码通过走廊流到测试部。测试部 agent 自动跑测试，失败的话通过走廊把 bug 报告送回工程部。你看着像素小人在屏幕上走来走去，但每一个走动都对应一次真实的 API 调用、一次真实的工具执行、一次真实的成本消耗。

这不是模拟游戏。这就是 StarNet。

核心设计：空间即程序

StarNet 最反直觉的地方是：UI 不是 runtime 的可视化，UI 就是 runtime 本身。

大多数 agent 框架的 UI 是"仪表盘"——agent 在后台跑，UI 展示状态。StarNet 反过来：你在 UI 里画的东西，直接定义了 agent 的能力边界、协作路径、权限范围。

具体来说：

• 一个房间 = 一个能力受限的团队：房间里的 agent 共享这个房间的能力集
• 一条走廊 = 一个授权的交接通道：只有有走廊连接的房间之间才能传递工作
• 一个放置的物件 = 一个真实的能力授予：放一个"GitHub 访问"物件，agent 才能操作仓库

这意味着：布局即架构。你想让工程 agent 不能直接碰数据库？那就别画从工程部到数据库的走廊。你想让所有 agent 都能用搜索？在每个房间都放一个"搜索"物件。

这不是"可视化配置"——这是空间编程范式。

产品契约：界面不得声称 harness 无法证明的状态

StarNet 有一条核心产品法则：

The interface must never assert state the harness cannot prove.

界面上的每一个像素状态，都必须有对应的运行时证据。如果界面上显示"agent 正在工作"，那这个 agent 真的在做 API 调用。如果显示"任务完成"，那真的有产出文件。如果显示"花费 $2.50"，那真的消耗了 $2.50。

这条法则的深层含义是：StarNet 拒绝"模拟"。

很多 agent 框架的 UI 会展示"agent 在思考""agent 在协作"——但这些状态可能是假的，可能只是 UI 动画在播放，后台什么都没发生。StarNet 把这个常见的欺骗彻底禁止了。

这条法则也意味着：如果你看到空间站里一片繁荣——所有房间都在亮灯、所有 agent 都在走动——那你的 agent 组织真的在高效运转。如果一片漆黑，那真的什么都没在做。 UI 不会骗你。

关键功能

多 Agent 并发，各有工作空间

每个 agent 是独立的运行实例，有自己的：

• 工作空间（文件系统隔离）
• 对话记录
• 记忆
• 权限边界

不是"一个 agent 多开窗口"，是"多个独立 agent 并发运行"。

Night Shift — 夜班模式

离开电脑后，agent 继续工作。但有一个"明确的、可调节的 leash"——每个夜间行动都被记录、可审查。

这个设计很精妙：它承认了"agent 自主运行"的需求（你睡觉时它们可以干活），但用"leash + 审计日志"来约束风险。不是放任不管，是"有约束的自主"。

Task Briefs — 不猜就问

遇到歧义时，agent 不 silent guess（默默猜一个答案），而是发一个 Task Brief：把歧义变成一个具体问题 + 几个选项，通过你连接的渠道（Telegram、Discord、Slack）问你。

这解决了一个真实痛点：agent 猜错了，你回来发现它花了 3 小时做错误的事情。Task Briefs 把"猜错的成本"替换成了"回答一个问题的成本"。

多渠道接入

Agent 可以连接 Telegram、Discord、Slack、Signal、Matrix。你可以在手机上通过 Telegram 和你的空间站 agent 对话，让它调整工作、审批任务。

这意味着：空间站是本地运行的，但交互是跨设备的。你的 agent 在你的电脑上跑，但你可以从任何地方和它交互。

MCP 连接器

支持 Model Context Protocol 服务器。可以接入任何 MCP 兼容的工具——数据库、API、文件系统。

真实的账本

花费、预算、运行历史持久化到磁盘，原样展示。不是"估计成本"，是实际消耗的 token × 价格。

和其他 agent 框架的区别

StarNet 和 Paperclip 代表了两个极端：

• Paperclip：agent 是员工，需要 org chart、层级、治理
• StarNet：agent 是空间站成员，需要空间布局、能力物件、走廊授权

两个隐喻都成立，但适用场景不同。Paperclip 适合 20+ agent 的大团队，StarNet 适合 3-10 agent 的个人或小团队。

深层洞察：空间编程范式

StarNet 最值得关注的不是像素艺术，是空间编程这个范式。

传统的 agent 配置是文本的：YAML 文件、JSON 配置、Python 代码。你需要读懂配置才能理解 agent 的能力边界。

StarNet 的配置是空间的：你看到的就是真实的。工程部到数据库没有走廊？那工程 agent 真的不能碰数据库。测试部没有"部署"物件？那测试 agent 真的不能部署。

这带来一个根本性的变化：非技术人员可以"编程"agent 工作流。产品经理可以画一个空间站布局，定义 agent 的协作方式——不需要写一行代码。

这和 No-Code 平台不同。No-Code 是把代码隐藏在 UI 后面。StarNet 是用空间关系替代代码逻辑——不是隐藏复杂度，是用一种更直观的表示方式消除复杂度。

限制和风险

1. 空间隐喻的表达力上限：不是所有工作流都能用空间布局表达。复杂的条件分支、循环、异常处理——这些用空间布局画出来可能比代码更难懂。

2. 本地优先 = 单机瓶颈：所有 agent 在你的电脑上跑。10 个 agent 同时做 API 调用，你的网络和机器扛得住吗？

3. "界面即运行时"的脆弱性：如果 UI 渲染出 bug，是否会影响运行时？界面和运行时的强耦合意味着 UI 问题可能变成运行时问题。

4. 像素艺术的"装饰性"争议：有人会觉得像素艺术是噱头，不是必需的。但 StarNet 的设计哲学是"空间关系即程序"——像素艺术只是空间关系的视觉表示方式。换成 3D 渲染或线框图，核心逻辑不变。

适用场景

• 个人/小团队的 agent 编排：3-10 个 agent，需要可视化协作
• 非技术人员参与 agent 设计：产品经理、设计师可以画布局
• 需要多渠道交互：通过手机 Telegram 远程控制桌面 agent
• 教育/演示场景：像素艺术 + 空间布局，非常适合教学和展示

结语

StarNet 提出了一个激进的设计哲学：界面不是 runtime 的可视化，界面就是 runtime 本身。

这个哲学的深层含义是：我们对"编程"的理解可能太窄了。编程不一定是写代码，不一定是配 YAML，不一定是拖拽流程图节点。编程可以是画一个空间布局——只要这个布局有明确的运行时语义。

StarNet 的核心产品法则——"界面不得声称 harness 无法证明的状态"——是一个值得所有 agent 框架学习的原则。它不只是 UI 设计原则，是诚实性原则：不要假装你的 agent 在工作，如果它没有在工作。

在一个越来越多的 agent 框架用花哨的 UI 动画来掩盖"其实什么都没做"的时代，这个原则比任何功能都重要。

StarNet 仓库：https://github.com/androoAGI/starnet
Trending 数据：日增 118 stars，JavaScript