别把项目送去 Agent 工厂，把 Agent 请进自己的 Realm
Agent 工厂可以比传统项目更快地做出一个能工作的产品。这是一项真实的进步。一个小团队可以在一个下午验证想法，一个从未打开过 IDE 的人，也能为家里或工作中的某个问题做出工具。但这样的工具一旦变得重要，它就不该为了每一个新改动都回到别人的工厂里去，而应该成为一个能按自己的规则邀请 Agent 进来的地方。我把这个地方叫作 Realm。
像 Lovable 这样的产品，会让这第一步很像把需求交给一座很好的 Agent 工厂。你说出需要什么，工厂已经有设备、预设配置、托管路径和很多现成部件，很快就能给你一个看上去完整的结果。把它叫作工厂不是贬义。工厂的价值，本来就在于把重复的部分做熟练。
然后项目的性质就变了。它开始承载客户数据、部署历史、域名、访问规则、源代码、测试、文档、人在压力下作出的决定，以及许多平时没人记得、迁移失败时才突然重要的小事实。难题会从“Agent 能不能做出来”变成“Agent 在做这件事时，这个项目究竟住在哪里”。
Realm 不一定是自建服务器，不一定要跑本地模型，也不只是一个 Git repo。 它是一个受控的运行与协作边界，让真正负责项目的人始终看得见它的资产、规则、历史、权限和部署决定。
Realm 至少要满足一个很实际的标准：有人能说清这个项目的数据和资源是什么，谁或什么有权对它们做哪些操作，一次改动留下的证据在哪里，以及帮手失误时如何恢复或更换部署路径。Git、身份系统、CI、云账户和运行手册都可能是答案的一部分。重点不是用一个神奇的新产品替换它们，而是让它们同项目之间的关系足够清楚，让一个新加入的人或新的 Agent 不必从碎片里重新拼出来。
要保持可读的是这些关系，不是必须由哪一家厂商独占。
工厂是很好的开始，不是坏东西
这里的差别不在于代码能不能从平台出来。以 Lovable 为例，它的官方文档说明，Lovable 支持 GitHub 导出和双向同步，项目可以在 pull request 中评审、在本地继续开发，也可以在 Lovable 之外部署。[1] 把这类产品说成牢笼，或者假装从里面做出来的项目不能长大，都是不准确的。
真正不同的是默认的重心在哪里。工厂式工作流里，平台从一开始就最了解这个项目。它知道项目模型、部署路径、托管服务，以及把一句提示变成可运行结果的那些默认假设。以代码仓库为中心的工作流则反过来，从项目目录和已有工具链开始。在它们的本地命令行工作流里，Claude Code 和 Codex CLI 都明确从用户要工作的项目出发，让 Agent 读取文件、使用本地环境已经具备的工具。[2][3]
这两种默认位置可以彼此交织。终端里的 Agent 仍可能调用远程模型，也会把上下文发给外部服务；托管式构建工具也可以把代码导出，进入普通 Git 工作流。真正要看的是默认由哪个系统承载项目的上下文，谁决定 Agent 可以碰什么，以及完成后的结果能不能被真正要长期承担后果的人看懂并继续维护。
这也回答了一个很实际的问题：从工厂开始的项目，完全可以长成 Realm。把代码导出来是重要的一步，但不是转变的全部。只有当真正负责它的人能回答四件事——数据和部署凭据由谁治理、Agent 可以改什么、可评审的证据落在哪里、一次坏改动怎样被停下或撤回——这个转变才算完成。工厂可以帮忙做这些事情，但它不必永远是这个协作边界的主人。
导出代码是重要一步，不是转变的全部。
如果只是一个可丢弃的原型，成熟的工厂可能正是最好的选择。没有必要为一个还没经受客户对话考验的想法，先花两个星期做地基。问题出在，一个很快做出来的第一版，悄悄变成了一个业务、一个社区，或者一家人的历史真正依赖的地方。第一公里很快，后面项目开始有了自己的生命。
一个项目不只是一份代码
人们常说：“把代码放到 Git 里就行。” 这当然必要，但并不够。没有运行上下文的代码仓库，就像一张没有水电管线、钥匙、地址，也没有解释某面墙为何必须留下的房屋图纸。文件可能都在，项目仍然很难运行、评审或安全地改动。
真正跟着项目走的，是比模型生成的代码更普通、也更重要的东西：它能读哪些数据，哪些密钥存在、谁能用，部署怎样通过，测试在什么条件下预期会失败，哪些行为是刻意的，以及某个今天看起来奇怪的决定当时是谁做的。文档、测试、配置、运行手册和变更历史不是琐碎的文书尾巴，它们是让下一个人，或者下一个 Agent，不必靠猜就能做事的上下文。
Realm 让 Agent 有一个被声明出来的落脚点。Agent 可以来自外部服务，可以使用托管模型，也可以只是临时进来帮一次忙。在读代码仓库、接触服务或提出部署之前，项目先决定它能看什么、能做什么，以及必须留下什么证据。
自托管并不会自动带来控制权。一台管理得很差的私有服务器，可能比一个边界、归属、恢复路径和评审流程都写清楚的托管环境更不容易被理解。反过来，一个项目即使使用云服务，只要它的边界、归属、恢复路径和评审流程都明确，仍然可以拥有真正的 Realm。比起每一颗 CPU 跑在哪里，更重要的是发生变化时，责任是否依然看得见。
请 Agent 进来，不等于把城市的钥匙交出去
一个 Agent 很有用，不等于它就该自动成为全能管理员。它越能做事，越需要分清楚什么是合理授予的能力，什么是没有边界的权力。
想象一个跨了几条边界的改动：应用要调整登录流程，改一份数据契约，更新相关文档，再动部署配置。一个好的 Agent 可以读到相关代码和规则，提出一个小的改动，跑真正相关的测试，然后留下可评审的变更。负责这个项目的人可以看见它碰了什么，决定它能不能进入生产环境；如果判断错了，也能把它撤回来。这种摩擦，是让第一版演示之后的迭代仍然可持续的条件。
如果同一个 Agent 只拿到一个很模糊的要求和很宽的权限，它就只能替你补全缺失的上下文。它可能选一个方便的库，复制一条已经存在的规则，改掉自己不理解的设置，或者做出一个根本没人能认真评审的大变更。问题不在于模型有恶意，而在于项目把“猜”变成了它最主要的接口。
这也是项目地基的质量会在此时显露出来的原因。清楚的权威来源、可以小步验证的改动、部署边界、读得懂的文档，以及不回避旧决定的记录，都会让一个强 Agent 真正变成杠杆。没有这些东西时，工厂往往会显得更好，因为工厂已经预先给了你一个受控的工作环境。这是工厂的优点，不是长期项目不需要地基的证据。
难的不是自主性，而是治理
人们已经在想象一个有很多 Agent 自动协调一切的未来。有些自主工作一定会做得很好。但没有清楚边界的更多 Agent，不会带来更多工程，只会更快制造混乱。
真正要回答的问题都不华丽。哪一种权限只能临时给？哪些数据本来就不该看见？哪些改动在评审前必须先留下证据？谁可以批准一次部署？一个错误的自动化怎样被停下、检查和恢复？下个月引入另一个 Agent 时，怎样不丢掉之前工作的含义？
没有人需要批准每一次敲键盘。真正的工作，是先决定人仍然要为哪些事情负责。细节可以委托，方向、权限和不可逆的后果，不能在不知不觉中被委托出去。
所以我也不认为某一个模型厂商、某一个构建工具，或者某一种命令行工具本身就足够。真正有用的环境，应该可以邀请不同类型的帮助。一个 Agent 可能更擅长完成首版界面，另一个更适合安全评审，另一个可以做迁移，还有一个能把系统解释给刚加入的同事。关键是这些帮助来来去去时，项目本身仍然是可读的。
对于一个希望在第一个 demo 之后继续活下去的项目，可以用五个问题做一个简单判断：
- 真正负责它的人，能不能找到它的数据、域名和部署凭据？
- Agent 开始前，能不能先说清它的权限，而不是出错后才发现？
- 一次被提出的改动，会不会留下评审者能看懂的证据？
- 一个错误的自动化，能不能被停下，并把改动撤回？
- 换一个工具或 Agent 后，它能不能不靠猜就继续之前的工作？
ARC 是对这个方向的探索，不是一份已经完成的承诺
ARC 正是在探索这个问题。ARC 是 Agentic Realm Computer。它的设计方向使用 AFS，把已授权的数据、可用服务和当前上下文放到统一的操作表面上，而 ARC 是 Blocklet 运行的运行时。它更像一种尝试：不是替换 Git 或 CI，而是让一个文件、一个已连接服务，以及治理它的权限，在更清楚的系统边界上相遇。应用和 Agent 不该每次都从彼此分离、又不透明的路径中重新拼起这些关系。
ARC 当然还没有解决这幅图景里的每一件事，把它写成已经完成的产品承诺是不诚实的。基于 ARC 的 Realm 仍然需要源代码管理、部署服务商、评审流程和恢复工作。ARC 并不声称要替换这些部分，而是在探索数据、授权、资源和运行上下文能否有一个更清楚的共同系统边界。一个未来的架构，仍要证明它能不能让权限保持可理解、让恢复真的可行、承接真实应用，并且与自身生态之外的工具一起工作。我之前写过另一篇相关的文章，讨论“软件被生成出来”并不自动等于“它是你拥有的软件”。那篇文章解释了为什么 ARC 要把长期身份和数据同某一次运行时分开。
这里更具体的一点是，Agent 需要一个立足之地。如果项目没有一个能承载上下文、权限、证据和历史的统一位置，请再多 Agent 只会让这种缺失越来越贵。Realm 是想在项目还没有重要到无法迁移之前，先给这些东西一个家。
工厂仍然会很有价值。它可以帮助人拿到第一个能工作的产品，也可能最终成为 Realm 能邀请进来的最好的一类 Agent。选择不在“漂亮的工厂”与“纯命令行”之间。更好的问题是：当项目真正重要起来，负责它的人还能不能看懂它、设定规则、替换帮手，并把它继续带下去。