一张图看懂它在跑什么
三层结构:上为 pi 核心引擎,中为 agent 基础设施,下为业务 / 开发 / 延展。连接线随滚动绘制,节点逐个入场,每层的数字都来自实际盘点。
极简内核,被我叠加成什么样
左边是 pi 出厂的样子,右边是我叠加之后的日常。两边都是同一份 pi,差别全在扩展物。
- 内置工具7 个
- 扩展物4 类 · TypeScript 直载
- 会话JSONL 树形 + /fork
- 上下文自动压缩 compaction
- 模型订阅 6 家 · API key 30+ 家
- 刻意不做MCP / sub-agents / 权限弹窗
- Skills85 个 · 24 通用 + 61 业务
- Agents20 个 · 含 16 个 rpiv 角色
- MCP4 个 · 上下文 / 图谱 / 浏览器 / 搜索
- Extensions~15 个
- 外部栈CI/CD · K8s · 密钥管理 · Kafka · 办公自动化
- 身份编排者 · APPEND_SYSTEM 五条
能力归类,五块拼图
从审美到工程,从办公自动化到车云,都是同一个技能库的切片。
设计与审美
×21把「不模板」写进规范:色板、排版、动效、图像方向,五个前端 skill 的综合。
办公自动化
×22办公自动化全家桶:从 IM 到审批,一条链路贯穿。
车云业务工程
xxx从代码提交到 K8s 部署的全链路,含 Kafka、密钥管理、VIN 扫描与报表。
工程效能
工具链上下文、代码理解、浏览器与终端自动化,把重复劳动交给工具。
智能体团队
×20一个编排者,加 19 个角色,跑在 rpiv 流水线上:先研究,再设计,后实现,最后验证。
一个干活的,一个把关的
编排者身份规定:研究必须派 sub-agent,不自己顺序执行,没有 review 不标完成。
牛马狗 workhorse
干活主力老法师 oldfox
把关编排者身份
APPEND_SYSTEM- 研究必须派 sub-agent,不让主线程自己做长调研
- 禁止自己顺序执行,能并行就并行,能派就派
- 没有 review 不标完成,交付前必须过一遍把关
- 不许假设问题已知,问题要先调查取证
- 证据说话,结论要有出处
配置快照,一页看全
主题、铁律、技能库与监控,都是当前真实生效的配置。
~/.agents/skills · 61 个业务
项目内 .pi/skills · 按需
AGENTS.md 六条铁律
每次会话自动注入- 先想后写,想清楚再动手
- 简单优先,不引入不必要的复杂度
- 外科手术式改动,只改需要改的
- 目标驱动执行,每一步都有目的
- 用 grep 不用 bash,搜索走专用工具
- 搜索走 anysearch,联网查询统一入口
另有一份 APPEND_SYSTEM.md,规定编排者身份的行为边界。