这半年我写了一串文章，论点其实是同一个：agent 不该是挂在某个环节旁边的提效工具，它该被放到组织的中心，让信息和判断默认先过它（个人靠第一推力，组织靠智能中枢）；而卡点从来不在模型智能，在能不能把组织里那些分散、隐性、口头的上下文，正确地喂给它（把整个组织喂给 agent）。
写到一定程度，有个问题就绕不过去了：这套东西落到一个真实系统里，到底长什么样？
光写理念是不够的。所以这几个月我也在真的造一个，原本只想作为内部工具使用的，但是现在把它开源了，叫 Greenhouse。
Greenhouse 这个名字的由来和 LetPot 有关，它的定位是组织内部工具，我希望它能够陪伴 LetPot 的成长，并且在组织内部孵化出更多有创意的产品和服务。
只需要执行一条命令就可以实现应用的完整自托管，给成员分配账号登录（不用装任何 app），而每一个能力，同时也能被外部 agent 通过 MCP 调用。这篇不讲怎么用，讲它的设计哲学：每一个架构决定背后，我在守的是什么。
一句话先摆在这：
如果 agent 是组织的中心，那产品的中心就该是一个工具层。你团队在 chat 里用的工具，和你暴露给外部 Claude、Cursor 的工具，是同一份。加一个能力，就是写一个文件。
它补的不是"个人提效"那一格
开源世界里 agent 相关的项目已经很多，但绝大部分还停在"个人工具"这一格：一个人在本地跑得很爽，能接模型、能调工具、能记忆。可一旦放进一个组织，它就缺了一整层东西，统一管理、数据权限分割、审计、协作，全都没有。
而这一层，恰恰是一家企业能不能真正用起 agent 的前提。greenhouse 补的就是这一格：可审计、可授权、统一管理企业的数据与知识库、可协作，以及可以让成员的个人 agent 接进来一起用。它不是又一个聪明的 agent，而是一个可管理的 agent 平台的地基。
我在 AI Agent 会重新定义 SaaS 里说过，agent 会把软件从"工具"变成"代理"。但代理要替一个组织做事，先得有一套能管得住它的地基：谁能调什么、动了什么要留痕、哪些数据对哪些人开放。个人工具不需要这些，组织离不开这些。greenhouse 想做的，就是这套地基的开源参考实现。
推进 AI native，只能自上而下
现在大多数 AI 进组织是自下而上的：员工自己先用起 ChatGPT、Copilot、各种个人 agent。这条路我不看好，至少不看好它能把一整个组织带过去。
自下而上的天花板很明显。员工自己用，提效优先，辐射面有限，各用各的，沉淀不到组织里。更要命的是，它一定会撞到数据权限和部门隔离这堵墙：一个员工的个人 agent，凭什么能看到跨部门的数据？没有自上而下的授权，它就只能在自己那一亩三分地里打转，做不成真正有杠杆的事。
所以我的判断是，要让一个组织整体转过去，方向得反过来：
工具和数据，应该自上而下地开放；上手，要做到足够容易，并且从 day 1 就给到能解决具体业务的工具和数据。
只有这样，员工第一次用，才会有那种"这玩意儿真能替我把活干了"的颠覆感，而不是又一个要自己捣鼓半天的玩具。这也是为什么 greenhouse 把统一管理、按人分发工具、自上而下的权限授予做成了一等公民，而不是事后补的功能。这跟我在 智能中枢 里说的是同一件事：AI native 是把组织重塑成 agent 的形状，是重塑，不是在旧流程旁边挂一个助手。重塑这种事，得从上面发起。
Tools：工具是 agent 的手脚
整个系统的设计里，最吃重的一个判断是：
工具能力是 agent 的手脚，决定了它能看到什么、能做什么，定义了它的活动范围。大部分应用的拓展点应该在这里，权限的分割点也在这里。
我在 Agent Harness 剖析 里拆过 agent 的 harness：它由工具、知识、观察、权限这些部件拼成。greenhouse 就是一个组织尺度的 harness，而它的重心，压在"工具"和"权限"这两项上。把这两项做对，agent 能干什么、不能干什么，就都立住了。
既然拓展点在这里，那加能力这件事就该足够轻。在 greenhouse 里，一个工具就是一个文件：你写清楚它叫什么、是干什么的、只读还是会改动数据、要不要对外开放，就这些，不用碰别的地方。
写完，它会自动出现在三个地方：团队成员日常用的聊天窗、本应用自己的 agent，以及外部的 agent（比如 Claude、Cursor）。你不用在这三处各维护一份清单，它们全是从这一个文件自动推导出来的。这看着像工程细节，其实是个原则：一份定义，三个入口。同一个能力，绝不会在不同入口上慢慢长成不一样的两套。
权限的分割点也在这一层，方向只有一个：只能收窄，不能放大。一个 agent 能拿到的工具，永远只是它背后那个用户已有权限的一个子集：只会更少，不会更多，没法凭空多出新权限。会改动数据的操作默认不放行，每次都得人点头确认，并且留下一条记录。还有一道底线：安全没配好（比如没设访问密码），服务干脆就不启动，绝不留"忘了配就全开放"的后门。
对外和对内的边界也在这里划清。对外公开的窗口只碰公开数据和公开工具，碰不到内部知识库；内部成员看到的，则是按各自角色和分配动态组装的工具；两者严格隔离。开放给外部 agent 的入口，绑定的是一个权限最小的内部账号，只能在它之上做减法。正是这条"只能收窄"的边界，才让我敢把组织的能力开放给外部 agent。
Generative UI：消息不止是文本
工具决定 agent 能做什么，还有另一半：它怎么把结果交还给人。这里有个判断：对话框里一律用纯文本回信息，对人来说不一定高效。一张表、一个图、一组能点的按钮，往往比一大段文字好读、好用得多。
所以 greenhouse 的聊天消息不是只会显示纯文本。当 agent 的回答里带了特定格式的内容（比如一段数据、一个图表、一个需要你确认的动作），界面会自动把它"升级"成一个真正能用的组件：一张可以排序、能搜索的表格，一张图，或者一组可以直接点的确认按钮。这样消息就不只是一大段文字，而是看得清、还能上手操作。
这里的取舍是：agent 自始至终只跟文字打交道，它不需要懂界面。它只管在自己的回答里吐出一段有固定格式的内容，至于这段内容最后变成什么样的组件，完全交给界面那一层去管。这跟我一直讲的"工具是能力描述，模型只管产出"是同一套思路，只是从"输入"那一侧搬到了"输出"这一侧。而且画面是边生成边更新的：前面已经画好的图表，不会因为后面文字还在往外冒就跟着闪来闪去。
更进一步，那种"确认"按钮不只是给你看的，它把你的一次点击接回了 agent 停下来等待的那一步：你点了"确认"，agent 才继续往下走。所以这套东西在这里不止是"好看"，它把人的操作直接编织进了 agent 干活的流程里。我在 Agent 交互的三层架构 里说过，agent 交互要从输入、输出一路讲到反馈，greenhouse 的这套做法，就是那个输出和反馈两层真正落地的样子。
Agent Profile：把最佳实践蒸馏成虚拟同事
工具层是手脚，那"用什么姿势干一件具体的活"是谁来定？在 greenhouse 里，是 profile。
每个成员都可以创建自己的 agent profile：起个名字、配张脸（真的有头像，颜色、配饰都能调）、写一段角色设定、挑它能用的一组工具、定几个常用动作。这就是把"我是怎么干这活的"蒸馏成一个虚拟同事。更关键的是它能分享：一键分享给全员，别人可以复制一份（fork）再去改造、优化，迭代出更好的版本。
这正是我在 Agent 的能力上限不在模型，在压缩率 里讲的那套逻辑，换了个场景。一个 profile 就是一份被压缩过的工作流程：把一个人的领域经验和最佳实践，压成一个可复用、可传播、可被别人继续优化的单元。区别在于，这次被压缩、被传播的不是一段 skill，而是"一个岗位的干法"。
再配上自动化，这件事就闭环了：定时让某个虚拟同事去跑一段任务，日常那些重复的活，比如每天早上的数据巡检、周期性的报告，就交给它自己去跑。一个团队用得越久，沉淀下来的优质 profile 越多，组织的"虚拟员工"队伍就越强。这是个会随时间复利的东西。
它给 agent 用，也是 agent 造的
最后一层，我觉得值得单独说：greenhouse 这套代码，实施部分几乎全是 agent 写的，但顶层设计是我定的，中间有些设计和 agent 共创，可拍板的永远是人。这跟我在 Loop Engineering 里的结论一致：执行可以整段交出去，方向不能。
造它的过程让我对"生成式开发"有了更具体的体感。写代码这件事本身不难了，难的是写出能不断适应新需求、还能维护得动的代码。我踩过的最深的坑是：代码生成太快，屎山一下就堆完了，等你要在上面接着开发，立刻束手束脚。哪怕有完整的测试套件也挡不住，因为功能堆到一定程度，一些产品设计上的假设会互相冲突、不够干净，留下我叫它"偏移点"的隐形 bug。所以这个仓库经过了很多次大规模重构，我的应对是尽量分层设计，能形成规范的就把规范沉淀下来，这是个渐进的过程。
也正因如此，这个仓库除了对人友好，本身也非常适合 AI 接着造。每一层都放了一份写给 AI 的说明书（AGENTS.md），讲清这一层的约定、边界、规则，这就是给"造它的那个 agent"准备的 harness。我甚至专门写了一节"反熵纪律"，把"只增不删、重复造轮子"点名为生成式开发的最大熵源，定下硬规矩：删一个东西，必须同步删掉它的文档、把所有还指向它的地方都清干净；想再写一个类似的实现，先说清为什么不能复用旧的。有了这套规范，agent 才能照着项目的要求继续开发、测试、发布，而不是每加一个功能就让熵涨一截。
一个给 agent 用的产品，本身就该是 agent 能接着造的产品。这两件事是同一种能力。
上手很简单：git clone 下来，一条 docker compose up 自托管，MIT 协议，加你自己的第一个工具就是写一个文件。想自建 AI native 内部平台的团队，可以拿它当地基；想搞清楚一个 agent 平台该怎么搭的开发者，可以拿它当参考实现。
我的思考
造完、也开源完，几个判断对我更清楚了。
第一，企业级 agent 平台的胜负手在 harness，不在模型。 模型是共享的，谁都能调。真正决定一个 agent 平台能干多少活、又安不安全的，是它的工具层有多好扩展、权限边界有多干净，以及它怎么把结果以人能高效接收的方式（generative UI）交还回去。这跟我讲过的 harness 壁垒是同一回事：能积累、能形成差异的部分，恰恰是工程能掌控的那部分。
第二，推进 AI native 是一项自上而下的工程，不是自下而上的渗透。 自下而上能让几个人用得爽，但带不动一个组织，因为它过不了数据权限和部门隔离那一关。要整体转过去，必须从上面把工具和数据开放下来，并且让员工第一次用就尝到解决真实业务的甜头。
第三，profile 是"压缩"在组织层的样子。 把一个人的干法蒸馏成一个可分享、可被 fork 优化的虚拟同事，让最佳实践在组织里复利地传播。这比"给每个人发一个通用 agent"有杠杆得多，因为它沉淀的是岗位经验，不是通用能力。
第四，一个给 agent 用的产品，本身就该是 agent 造的。 难的不是写代码，是写出能持续适应新需求、维护得动的代码。这要求人退到设计和拍板那一层，把约定和边界用 AGENTS.md 沉淀成给造它的 agent 看的规范。人退出的是执行，不是责任。
于是我自己的位置也变了：能交出去的都交出去，剩下设计工具层、划权限边界、定方向这几件，是我还得自己守的。greenhouse 是我对"agent 当组织中心到底长什么样"的一个回答。