字节笔记本
2026年10月5日 · 约 9 分钟读完
72 小时设计一个 Agent，却只公开架构不开源代码
大多数开发者公开作品时只有两种选择：要么全开源（代码加文档），要么完全闭源（什么都不说）。
最近，一位开发者在 X 上分享了一个很特别的案例：她花 72 小时设计了一个 OPC Agent，把去隐私化的完整架构图公开了，甚至说"喂给 AI 预计 15 分钟就能实现"，但代码本身不开源。
这乍看矛盾：既然架构都给了，AI 也能照着复现，为什么不直接开源代码？
但仔细想，这其实是 AI 编码时代一种全新的"开放"姿态，而且逻辑自洽。本文就来聊聊这个现象。
原作者公开的 OPC Agent 去隐私化架构图。
一、先看懂她做了什么
这条分享的核心信息有五点：
- 花 72 小时设计了一个 OPC Agent；
- 已完成去隐私化处理，把架构图里所有敏感信息（密钥、私有端点、个人数据等）清理干净；
- 架构图完全公开，模块、流程、技术选型都看得见；
- 可任意复用，明确鼓励大家拿这个架构去用；
- 但代码不开源。她的原话是："你可以跟我说让我直接开源……但是这样反而降低了我精神股东们对我的审美力判断"。
最后那句是关键。她的意思大致是：如果直接把能跑的代码交出去，大家就只关注"能不能用"，不再欣赏设计这东西的审美和判断力了。
二、为什么不直接开源？逻辑其实很清楚
很多人第一反应是"装"或"矫情"。但顺着这套逻辑走一遍，会发现这是一种理性的策略选择。
理由一：架构才是最值钱的部分
在 AI 编码时代，代码的价值在快速贬值，因为 AI 能照着架构把代码写出来，原作者自己都说"喂给 AI 预计 15 分钟就能实现"。
那什么还值钱？架构判断力、审美、设计决策。这些是 AI 短期内替代不了的：决定用什么技术、模块怎么切分、数据怎么流、用户体验怎么设计。
公开架构等于展示判断力；开源代码则是把 AI 也能生成的部分丢出去，反而稀释了对判断力的关注。
理由二：保留"精神股东"
她说的"精神股东"，指的是关注她、欣赏她作品的人。如果直接开源代码，社区焦点会变成"能不能跑""有没有 bug""为什么不支持 X"，一头扎进技术维护的泥潭。
而只公开架构，社区的互动是"这个设计真巧妙""这个模块划分有意思""我也想按这个思路做一个"，保持在欣赏和讨论的层面，而不是索取和抱怨的层面。
这是一种主动管理社区注意力的策略：让别人看到"设计脑子"，而不是把自己变成免费客服。
理由三：可复现，但要费你自己的力气
"喂给 AI 15 分钟能实现"并不夸张。有了完整架构图加技术选型，让 Claude Code、Cursor 这类 agent 照着写，大概率能跑起来。
但关键区别在"你来写"，不是"我给你"：
- 我给你代码：你直接用，你不理解，出了 bug 你找我；
- 我给你架构：你自己（或你的 AI）实现，你理解每一行，出了 bug 你自己改。
公开架构不开源代码，本质是"授人以渔而非授人以鱼"。传递的是设计模式，不是成品。
三、这其实是一种历史悠久的传统
这种做法并不新，软件行业里早有先例。
Unix 哲学的传播。 Unix 的设计哲学（小工具、管道、组合）是通过论文、演讲、书传播的，不是通过某一份代码。大家学到的是思想，然后各自实现。
设计模式的普及。 《设计模式》讲了 23 种模式，没给任何具体代码，给的是结构的描述。但全世界程序员照着实现了无数次，影响了整个行业。
论文与代码。 学术界的常态是发论文（讲方法和架构）、不发代码，别人要复现就照着论文自己写。近年来才兴起开源代码的运动，但论文仍然是主要的思想传播载体。
这位开发者做的事，本质是"发了一份架构论文"。在 AI 能写代码的今天，这种"只公开设计、不公开实现"的做法，反而可能成为更主流的开放形态。
四、AI 编码时代，"开源"的定义正在分裂
这是整条分享最值得思考的地方。以前"开源"是一体的：代码、文档、设计都在一个仓库里。但 AI 编码能力变强后，这几样东西的价值正在分化。
代码实现贬值最快，AI 能照着架构直接生成；架构设计和问题域理解最值钱，需要人的判断、审美和对业务的真懂；文档和部署运维经验居中。
当代码不再是稀缺品，"开源代码"的意义就在下降。真正稀缺的是架构判断、审美、对问题的理解、设计决策的理由。
选择开放稀缺的（架构），不开放不稀缺的（代码），恰恰是价值最大化的开放方式。
五、给普通开发者的四点启示
不管你同不同意这种做法，这套策略对每个开发者都有启发。
启示一：多展示"为什么这么设计"，而不只是"我做了什么"。 大多数开发者分享作品时只说"我做了一个 X"，这是在展示产出。更值钱的是展示决策过程：为什么选 A 不选 B、为什么这个模块这样切、踩过什么坑。架构图加设计理由，比一堆代码更能展示判断力。
启示二：练习"读架构图，让 AI 实现"这个新技能。 下次看到别人公开的架构（不管开不开源代码），可以把架构图加你的需求描述丢给 Claude Code 或 Cursor，让它照着实现。你可能会惊讶于 AI 能复现到什么程度。
启示三：想清楚让社区关注什么。 如果你做开源，想清楚目标：是让大家用你的代码（那就要像维护者一样待命），还是让大家讨论你的设计（那就多发架构和思考，少发实现细节）。不同的目标对应不同的开放策略。
启示四：找到你自己的"开放光谱"。 在"完全闭源"和"完全开源"之间，其实有一大片光谱。
从完全闭源、公开效果图、公开架构图、公开核心算法、公开部分代码，到完全开源，甚至放弃所有权利进入公有领域，每一档都是合法选项。你的下一个项目，可以根据目标选最适合自己的那一档，不必非黑即白。
六、争议：这是"真开放"还是"蹭流量"？
公平地说，这种做法也有争议。
支持方认为：架构公开且可复现，已经足够开放；保留代码反而逼使用者深度理解；而且应当尊重创作者对作品的处置权。
反对方认为："AI 15 分钟实现"有夸张成分，真做过的都知道，架构到能跑的代码之间还有无数细节；只公开架构不开源代码，有"既要名声又要保留商业化空间"的嫌疑；真正的开源精神是完整可复现，不是"给你个图自己琢磨"。
本文的看法是：两种观点都有道理，关键是创作者有没有诚实标注自己开放到什么程度。这位开发者明确说了"不开源代码，只给架构"，没有假装开源。只要诚实标注，公开到哪一档是她的自由。真正值得批评的是"既不开源又宣称开源"的行为，而不是"公开架构但不公开代码"。
七、回到 OPC Agent 本身
至于这个 OPC Agent 的架构设计本身，从公开的架构图看，它是一个多模型代理与编排层的方案，核心特点有三个：
- 去隐私化处理，这是关键的安全设计，先把密钥、私有端点和个人数据从架构图里清理干净；
- 可任意复用的架构，模块解耦，拿到图就能按自己的需求改造；
- agent-native 思路，为"人和 Agent 一起使用"设计交互。
这类思路近年并不孤立：社区里一直有"一次定义、多端复用"的 agent-native 接口设计，也有让 Agent 直接编排调用服务的产品探索，还有不少自带模型、自管推理的工具。OPC Agent 的多模型代理加可复用架构，可以看作这一方向的延伸。Anthropic 在近期的趋势报告里也提出，工程师的工作正从写代码转向编排 Agent，"公开架构、让 AI 实现"正是这种转变的一个具体样本。
具体技术细节因为代码没开源，只能从架构图推断。但从投入的 72 小时和公开的诚意看，这套架构是认真打磨过的。
八、结语：AI 时代，"开放"正在重新定义
这条分享最值得记住的，不是 OPC Agent 本身，而是它无意间示范的一种新姿态：当 AI 能写代码，"代码"就不必是开放的全部。真正值得开放的，是 AI 还替代不了的判断力、审美、设计思想。
这未必是"正确的"开源观，但它提出了一个真问题：在 AI 编码时代，"开源"这两个字的内涵，是不是该更新了？
以前开源等于公开源代码。以后开源会不会变成"公开设计，让 AI 帮每个人实现自己的版本"？如果是后者，那么每个开发者的核心竞争力，就不再是"写了多少代码"，而是"做了多少好决策"：架构怎么切、技术怎么选、体验怎么设计。
72 小时加一张架构图，给这个问题提供了一个生动的注脚。不管你同不同意这种做法，这个现象值得每个关心软件行业未来的人想一想。
本文基于一位开发者在 X 平台的公开分享整理；文中对"公开架构不开源代码"的分析为作者观点，不代表对当事人个人选择的评判，OPC Agent 的具体实现以原作者后续公开为准。
