月初写了《老板，别再折腾开源 Agent 了》，结论是：开源 agent 是工程师的活，老板的注意力该留在业务上。发出去之后，被问得最多的一句是：行，那工程师该干什么？
这篇是我的答案的一小部分。过去一年多，我把「Agent 要在组织里干活，到底缺什么」拆成了三块底座，每块写成一个开源项目，最近都放出来了。先讲为什么是三块，再讲各自是什么。
三块底座，缺一块就落地不了
一个 Agent 要从演示走进组织，光聪明没用。它得先回答三个问题：
它依据什么说话？ 这是知识。新旧规则谁作数、这句话出自哪份文件第几页、这份资料能不能给客户看——答不上来，Agent 只会更快地放大原来的混乱。之前写 RAG 那篇说的就是这层：缺的不是另一个聊天框，是可追溯的知识底座。
它干完的活记在哪？ 这是任务。人干活有工单、有清单、有验收；Agent 干的活如果只留在聊天记录里，等于没干。任务得有一张人和 Agent 共用的清单：Agent 领任务、交结果，人来验收。
它在哪儿干活？ 这是运行时。组织的工作发生在飞书群里，不在某个网页聊天框里。谁允许这个 Agent 进群、它能调哪些工具、干过什么有没有记录——这些是组织层面的约束，不是模型能力。
知识是「知道什么」，任务是「要做什么」，运行时是「在哪儿干活」。三块齐了，Agent 才算有了工位。
三个项目
先说名字的来历：琅嬛是传说中天帝藏书的地方；璇是北斗的枢机，础是基石；瑶光是北斗七星里斗柄上的最后一颗，负责指方向。一个藏书，一个奠基，一个指方向——回头看，正好对上三块底座。
琅嬛 · Langhuan（知识）：可单二进制部署的知识库 MCP。把 PDF、DOCX、表格这些文档变成可检索、可追溯的资料——每个片段都能回到源文件的页码和位置——再通过 MCP（一套让 AI 调用外部工具的标准协议）交给任何 LLM 或 Agent。它不生成答案，只把知识备好。检索质量做过公开评测，过程见《给检索系统造一把尺子》。
璇础 · Xuanchu（任务）：给人、也给 Agent 用的任务系统。一个 Go 二进制，同时是命令行、网页控制台、HTTP API 和 MCP 服务：人用命令行或网页管任务，Agent 走 MCP 领任务、更新状态、交结果。它借鉴了 Taskwarrior 的查询思路，但补上了它没有的东西：多租户、权限和审计——平时看不见，一旦 Agent 开始替你干活，每一样都是刚需。
瑶光 · Yaoguang（运行时）：把 Agent 放进飞书群。群里 @ 它就能派活：它调工具、查资料、回群汇报，成员权限与审计追踪一并管住。它自带一个基础知识库，需要更强检索时可以直接接琅嬛。
拼起来是什么样
走一遍真实流程：在飞书群里 @瑶光，「把新版报销规整理成任务」。瑶光先到琅嬛查旧规、核对每条的出处，再把差异写成几条任务放进璇础，指派给对应的人，干完回群里汇报。每一步有审计记录，每条依据能回溯到源文件。
这三件事单独拿出来，都有现成产品；但按「知识—任务—运行时」拼在一起、并且全部开源的，我还没见到。这是我动手写它们的理由：与其等一套闭环出现，不如把缺的底座一块一块垒出来。
边界说清楚
三个项目都还很新（GitHub star 都是零起步），别直接拿去接生产。写它们也不是为了替代谁——恰恰相反，是把「组织要用 Agent，到底缺什么」这个判断，用代码公开出来接受检验。
上一篇的结论不变：你是老板，成品优先，别自己养虾。你是工程师，或者真有自建的需求——三个仓库都在 GitHub 上：琅嬛、璇础、瑶光，欢迎拿去用、来提 issue，我们一块把底座垒结实。