我是 Wolf 的作者。Wolf 是一个开源 RBAC 权限系统，维护了五年多，一直在做「稳」的事——加字段、修 Bug 、补文档。
0.7.1 之后终于做了一件真正大的：在 Console 里内嵌了一个 AI Agent ，可以用自然语言直接管理 RBAC。这是 Wolf 五年来最重要的功能更新，没有之一。
整个 Agent 框架基于 pi-mono（@mariozechner/pi-agent-core + @mariozechner/pi-ai），不是另起炉灶写一套管理后台，而是让 AI 通过 Tool Calling 去调 Wolf 现有的 Controller——鉴权、参数校验、缓存刷新、审计日志，全部走原链路。
能干什么
说人话就是：你在 Console 左侧点「 AI 助手」，然后直接聊：
- 「
oa-app下有哪些角色？每个角色绑了哪些权限？」 - 「在
pi-mono下新建一个viewer角色，把所有read_开头的权限给它。」 - 「最近 7 天有没有 403 的访问记录？」
- 「重置用户
lily的密码。」
AI 能做什么 = 当前登录用户在 Console 上能做什么，不会越权。所有写操作进 access_log，appID = 'ai-agent'，和人工操作区分开，事后能查。
覆盖了 8 个领域、31 个工具：Application / User / Role / Permission / Resource / Category / UserRole / AccessLog 。
几个设计上我比较在意的点
1. 不是 SQL 直连，是复用 Controller
后端用 InternalCaller 构造 mock Koa ctx ，进程内调现有 Controller 。AI 不是数据库后门，工具权限还会按 super / admin 自动裁剪。
2. 完整的聊天体验
- 多会话：新建 / 切换 / 重命名 / 删除，AI 自动总结标题
- SSE 流式输出，工具调用有独立卡片（ running / done / error ）
- Markdown + Mermaid 渲染，查权限关系可以直接出图
3. 用户记忆
新建会话时，AI 会异步从上一段对话提取「记忆」（偏好 / 已知信息 / 历史决策 / 操作模式），下次自动注入 System Prompt 。也可以手动增删改。
4. 多 Provider
OpenAI 兼容网关、Anthropic 、Gemini 、Mistral 、Groq 、OpenRouter 等都支持，环境变量或 config.js 配置。没配 Key 也不影响 Wolf 其它功能，只是 AI 页会友好提示。
这次改了什么（相对 0.7.1 ）
0.7.1 → 当前 master，5 个 commit ，117 个文件，+24063 行：
| 模块 | 内容 |
|---|---|
后端 server/src/ai/ |
Agent 工厂、系统提示词、记忆提取、会话标题生成、8 组 Tool |
控制器 ai-chat.js |
SSE 流式对话、会话 CRUD 、消息持久化 |
| 数据库 | 新增 ai_chat_session / ai_chat_message / ai_user_memory 三张表 |
前端 console/src/views/ai-chat/ |
完整聊天页：会话列表、消息气泡、工具卡片、记忆面板 |
| 安全加固 | Cookie 安全属性、开放重定向防护、应用级访问控制、Captcha 一次性销毁等 |
| 测试 | 新增 ~5000 行 AI 相关单测 / 集成测（工具、中间件、控制器、SSE 等） |
| 文档 | README-AI-AGENT-CN.md、docs/ai-agent-cn.md、截图 12 张 |
开发过程 & 花了多少钱
这次是 AI 辅助开发（ vibe coding ） 全程：
- 主力：Cursor（ Claude 模型），2 次订阅，20 刀 + 20 刀 = 40 刀
- 验证阶段：Claude + MiMo v2.5-pro（小米赠送额度）跑测试用例和回归，用了约 25M Tokens
40 刀换来的是：117 个文件、+24063 行代码、完整的前后端 + 测试 + 文档。说实话，用 AI 写 AI 功能这件事本身挺魔幻的——某种程度上是 AI 在帮自己造运行环境。
为什么不写 Skill ，而是直接集成 Agent ？
也有人问过：为啥不写一个 Skill / MCP ，让 Cursor 、Claude Code 、Hermes 、OpenClaw 这类外部 Agent 去调 Wolf API ？
Skill 当然也能把接口定义清楚，但它是开发者工具——Wolf 的用户是运维和管理员，不是人人桌上都有这些 Agent 客户端。内嵌 Agent 是产品能力：浏览器登录就能用，AI Key 管理员统一配。
另外，内嵌方案工具进程内直调 Controller ，和点表单走同一条链路；鉴权、审计（appID = 'ai-agent'）、按角色动态裁剪工具列表，都天然对齐。成功率、流式输出、工具卡片、Mermaid 图、会话记忆这些，也更适合做成 Console 里的一体化体验。
一句话：Skill 适合个人提效，内嵌 Agent 适合把 AI 做成产品功能。
如果你也想给存量系统接 Agent ，我的体会是：
- 先钉死边界：AI 只能走现有 API/Controller ，别让它直连 DB
- 工具粒度对齐业务接口：一个 Controller 方法 ≈ 一个 Tool ，权限自然继承
- 测试要舍得写：Agent 行为不确定，单测 + 集成测是兜底
- 选个成熟的 Agent 运行时：pi-mono 的 streaming / tool loop 省了不少轮子
链接
- 项目： https://github.com/iGeeky/wolf
- AI 助手文档： https://github.com/iGeeky/wolf/blob/master/docs/ai-agent-cn.md
- 功能速览： https://github.com/iGeeky/wolf/blob/master/README-AI-AGENT-CN.md
Docker 快速体验：quick-start-with-docker/docker-compose.yaml 里 server 服务已预留 AI 环境变量，至少配这几项：
AI_API_KEY=sk-... # 必填
AI_PROVIDER=openai # 或 deepseek / anthropic 等
AI_MODEL=deepseek-v4-flash # 具体模型 ID
AI_BASE_URL=https://api.deepseek.com/v1 # OpenAI 兼容网关地址
docker compose up 后登录 Console ，左侧点「 AI 助手」即可。
欢迎 Star / Issue / PR 。
做完这个功能，我意识到：权限管理这件事之所以烦，不是因为逻辑复杂，而是因为要点的表单太多。现在 AI 能替你点了，感觉权限系统该有的样子本来就应该是这样的。
如果你也在做「给老系统接 Agent 」或者对 Wolf 感兴趣，评论区聊聊。
Select Language