让智能体像人一样学习和工作，共享智能体和项目记忆
# Agents Universe
[](https://agents-universe.com)
[](LICENSE)
[](https://github.com/agents-universe/agents-universe/actions/workflows/ci.yml)
[](https://www.python.org/)
[](https://vuejs.org/)
开源共建 · 技术平权 —— 让智能体像人一样学习和工作。
Agents Universe 是一个开源的企业级 AI Agent 平台。它不是又一个"更聪明的聊天框"，而是要让智能体真正成为能干活的人：入职读懂文档、接任务先规划、以个人身份与权限执行、留下可审计的轨迹——并把这一切沉淀为每个人都能复用、共同建设的资产。
Codex 式三栏界面：左侧会话与项目导航，中间对话流，右侧计划与知识上下文（点击可查看大图）
### 🚀 它正在管理它自己
>
本项目已部署在 [agents-universe.com](https://agents-universe.com)，并且正在被它自己管理。 平台上的 Product Owner 与 Tech Lead 智能体，就是这个仓库的日常维护者：需求、代码、PR 都由智能体们在对话中完成。
>
因此——给这个项目做贡献，不需要会写代码。注册账号、配置你自己的模型 API Key 与 Git Token，然后和 Product Owner 聊需求，聊得差不多 @Tech Lead 告诉它要实现哪个，即可完成协作提交 PR。详见 [零代码共建](#零代码共建用对话为项目做贡献)。
## 愿景：技术平权，始于开源
今天，一个智能体好不好用，几乎取决于"是谁调教的"。资深工程师的智能体可以独立交付整个功能，而普通人面对同样的框架，得到的往往是一个"会聊天但干不了活"的助手。智能体的能力被锁在个人的 Prompt 与上下文里：人均而异、无法复制、不可传承。
我们相信，这不应该是一种常态：
## 为什么做这件事：智能体的"两极困局"
今天的智能体产品站在两个极端。
一端是开发者框架 —— Claude Code、VS Code AI 等。 自由度与上限都极高，但：门槛极高（要懂代码、会写 Prompt、会管理上下文与工具）；效果天差地别（每个人的智能体是不同的智能体，结果不可复现）；经验无法传承（调教技巧留在个人对话里，团队无法共建、复用）；非技术人员几乎不可用。
另一端是低代码平台 —— Dify 等。 上手简单，但设计理念从"知识库 + 应用配置"出发：智能体能力是补充而非核心（自主规划、任务执行、工具使用被简化成配置节点）；更像"应用"而不是"员工"（没有个人身份、最小权限与可审计的执行轨迹）；企业落地不适配（共享权限难以追责，复杂场景触及平台能力边界）。
### Agents Universe 的答案：让智能体像人一样
| 像人一样 | Agents Universe 的做法 |
|---|---|
| 学习：入职读文档，干活中不断更新 | 项目选中即全量加载知识；交给它的文档提取后整理进对应知识条目，工作全程持续迭代；[[slug]] 显式表达业务结构；模糊决策主动向用户澄清 |
| 工作：接任务、拆任务、执行、汇报 | plan_task 拆解任务树；按上下文选择工具；个人身份与权限执行；WebSocket 实时可见 |
| 传承：老带新，经验沉淀 | 技能（Skills）、工作流（Workflows）与知识条目把个人经验变成组织资产；开源共建，人人可用 |
## 为什么能做到：经验即资产
"像人一样"不是宣传语，而是三条底层设计的结果——学习靠读写、工作靠边界、能力靠传承。
[[slug]] 是目录与参考文献式的显式结构，拿不准就主动澄清。上下文完整，理解才完整，工作才不会跑偏。api-map.md、指标进 metric-catalog.md、测试经验进 test-patterns.md，而不是把原文堆在上下文里。工作过程就是迭代过程：每次测试校正、每次口径裁定、每个新接口，都通过 knowledge_rw 回写；过时条目标注 [stale]、确认后退役，全部变更记入 history.md。项目越用越懂自己，这就是智能体的"工作经验"。plan_task 先规划再动手；密钥加密、明文不进 LLM 上下文，以个人身份与最小权限执行；思考与执行全程 WebSocket 可见可审计。没有边界的自主是失控，没有自主的边界是脚本。## 智能体是如何学习的
愿景是让智能体像人一样学习和工作——而人学习从来不靠"换一个更聪明的大脑"，靠的是几件具体的事：入职先读文档、干活中学本事、记错会改正、出师带新人。Agents Universe 把这四件事做成了闭环机制，让智能体的能力随使用不断成长：
入职读懂项目 → 干活中学本事 → 经验沉淀为资产
↑ │
└────── 新项目继承资产 · 再出发 ──┘knowledge-ingestion 工作流学习：判断文档归属（业务规则进 domain/、接口进 technical/、操作手册进 skills/）、提取有用信息、总结成带 [[slug]] 交叉引用的结构化知识条目写回项目——API 文档按"索引 + 按服务 detail"两级归档，发现已有相似条目会先问你是更新还是新建，绝不重复。之后每次选中项目，knowledge/loader 把学到的知识两级加载：primary 文件全文读入上下文，detail 文件按需再取——没有向量检索的碎片召回，理解建立在完整上下文之上，而不是命中碎片之上。knowledge_rw 把新学到的东西写回知识条目：新接口进 api-map.md、指标口径进 metric-catalog.md、测试经验进 test-patterns.md——只提取信息、归类整理，而不是把原文堆进上下文。每次写入立即重新索引：完整度打分更新、旧版本全文留档（knowledge_versions）、WebSocket 实时同步进度；API 文档超过阈值时强制拆成"索引 + 按服务 detail"两级结构，防止知识文件长成无法通读的一团。load 进上下文，任务完成自动 unload 释放；超出上下文预算的文件只列目录供按需读取。和人的工作记忆一样——手边只放当前任务需要的东西。[stale]，经用户确认后退役；全部变更记入 history.md，残留的索引行由 purge 清理。遗忘不是数据丢失，而是可审计的修正——人会记错，重要的是及时更正。## 核心特性
## 敏捷开发三智能体：一支 24 小时在线的小团队
平台内置的三个敏捷角色——Product Owner / Tech Lead / Quality Assurance——组成一条完整的 需求 → 实现 → 验证 交付链路。它们都遵循"知识优先"原则：选中项目即全量加载项目上下文（业务背景、词汇表、页面地图、API 清单、测试模式、历史记录……），通过 [[slug]] 交叉引用互相衔接，任何工作都建立在项目的全部上下文之上，而不是孤立的一次性对话。
### Product Owner — 需求侧