106 posts tagged with "AI Agent"

Skills Manager 解决多 AI 编程工具 Skills 分散管理的痛点，15+ 工具用一套中央库 + 工作区 + 预设搞定，再也不用手动复制。

• 痛点：每个工具自己一份 Skills 目录，复制几次后不知道哪份是新的
• 解法：中央技能库统一托管，跨工具一键同步（复制或软链接二选一）
• 三层工作区：全局（每工具默认生效）/ 项目（仅当前项目生效）/ 预设（一组常用技能打包）
• 跨设备同步：接私有 Git 仓库自动备份，冲突时本地版不会被覆盖
• 适用：同时用 2+ AI 编程工具 / 自己写 Skill / 团队共享常用技能
• 边界：偶尔用网页聊天的人先不用装，装任何 Skill 前先看 SKILL.md

Pi 把上下文压缩做成一等公民：自动触发、结构化摘要、可扩展、可手动控制。两种机制——压缩和分支摘要——共用同一套文件跟踪与摘要格式。

1. 触发条件：上下文超阈值或 /compact 触发压缩；/tree 切分支触发分支摘要
2. 核心字段：reserveTokens（默认 16384）、keepRecentTokens（默认 20000）
3. 七段式摘要 schema：Goal / Constraints / Progress / Key Decisions / Next Steps / Critical Context
4. 关键设计：重复 compaction 从上一 compaction 的保留边界开始，磁盘上只有「三块」而非 N 段
5. 累积文件跟踪：read/modified 文件清单跨多次 compaction 累积
6. 可扩展：session_before_compact 钩子允许扩展完全替换摘要生成

DESIGN.md 是 Google Stitch 提出的设计系统规范，把 token 化的视觉语言写进项目根目录。

1. 痛点：AI 写组件超过 5 个，颜色 / 间距 / 圆角就开始漂移
2. 解法：把9 大模块（视觉主题 / 色彩 / 字体 / 组件 / 布局 / 深度 / Do's / 响应式 / Agent 指南）写进 DESIGN.md
3. 格式：YAML Front Matter + Markdown 正文，机器可读 + 人类可读
4. 生态：awesome-design-md 70+ 品牌（9.6 万 Star）+ getdesign.md 索引站 + Chrome 扩展 逆向竞品 + webdesignhot 403 个 CLI 模板
5. 本质：和 AGENTS.md 平行的"视觉约束文件"
6. 局限：直接套别人的设计只适合原型 / 内部工具，自有品牌仍得手写

book-to-skill 把一本书拆成 Claude Code 可按章节调用的 Skill，解决"买了书两个月就忘"的痛点。

1. 痛点：书看完两个月只剩一句"好像讲过"，问 AI 拿到的是东拼西凑的通用建议
2. 解法：一句 /book-to-skill ~/path/to/your-book.pdf 把 PDF/EPUB 转成 ~/.claude/skills/<slug>/
3. 机制：按章节按需加载，不一次性塞全本——更快、更便宜、不幻觉
4. 效果：同一问题，普通 AI 给通用建议；用 Skill 后直接基于原书框架分析
5. 适用：工具书/方法论书/技术书，不适合小说散文
6. 边界：目前一次拆一本，跨书检索、增量更新还没设计

Draw.io MCP 三种方案横评，方式 3 是唯一支持协作画图的解。

1. 方式 1（官方 drawio-mcp）：走 jgraph/drawio-mcp 远程生成，每次都是新文件，原图没法覆盖。
2. 方式 2（官方 Plugin + Desktop）：能本地覆盖原文件，但 不支持实时编辑，要手动 reload。
3. 方式 3（推荐，next-ai-draw-io）：本地起 localhost，真正支持实时编辑，Agent 改一步你能立刻看到。
4. 结论：想让 Agent 协作式画图，方式 3 是目前唯一解。

Pi 把「一次会话」抽象成一颗 JSONL 树。每条 entry 是一个节点，节点之间靠 id 和 parentId 串成父子关系；当前活跃的位置是「叶子」。

1. 存储：JSONL 树形文件，按工作目录分组存到 ~/.pi/agent/sessions/
2. 数据格式：每行一条 entry，类型由 type 字段区分，节点靠 id/parentId 串成树
3. 消息模型分两层：pi-ai 给基础 LLM 类型，pi-coding-agent 扩展出 BashExecution / Custom 等专用消息
4. BashExecution 是 Pi 特有：把 !、!! 命令结构化地放进会话，跟普通 tool result 分开
5. custom vs custom_message：前者只存盘不进入 LLM context，后者进入 context
6. 树形的设计：撑起分支探索、无损压缩、多事件流并行

Pi 把 Session 设计成树而不是线，不是「数据结构的偏好」，而是支撑所有核心能力的基础。

Pi 用一句话定义自己：核心要小，行为由扩展装配。

1. 核心极简：默认不内置 MCP、sub-agent、plan mode、to-do、权限弹窗
2. 4 个 npm 包：pi-ai / pi-agent-core / pi-coding-agent / pi-tui，单向依赖
3. 最底层是 pi-ai：纯 LLM 适配，零 agent 概念
4. 分层好处：每一层独立 npm 包，按需引入
5. 核心只做四件事：加载扩展、跑 agent 循环、读写 session 文件、提供 TUI

记忆点：Pi 卖的不是「帮你做好了一切」，而是「给你一块可改装的底盘」。

codebase-memory-mcp 是一款纯 C 编写的代码知识图谱 MCP 服务器，给 Claude Code / Codex / Open Code 装上"项目结构感知"能力。

1. 核心定位：用 MCP 把代码库索引成可交互的知识图谱，AI 改代码前能感知调用链、依赖与爆炸半径。
2. 架构特点：零依赖单文件二进制，不依赖 Node / Python 环境，下载即可跑。
3. 能力边界：支持 158 种语言、内置 20+ 语义关系、支持 OpenCypher 图查询。
4. 对比 CodeGraph：提取精度 / 调用图完整性 / 查询能力 三项领先，索引速度落后，平均分几乎持平。
5. 典型场景：快速上手陌生项目、PR 影响半径分析、死函数检测、跨语言特性迁移。
6. 代价：单次索引 20+ 分钟，MCP 集成会占用系统资源，且与 GitNexus 跨仓能力有差距。

Claude Code 的代码检索不靠 RAG，靠 grep。这是 Anthropic 工程师 Boris 在 2025 年 5 月 Latent Space 博客里公开承认的工程决策。

1. 事实层：Boris 公开承认过，Claude Code 早期试过 RAG，发现效果不行就切到了 grep
2. 技术层：三个根本原因——embedding 对代码失效、管线准确率乘性效应、索引时效性漂移
3. 哲学层：无状态设计 + Everything is the model，对应 Bitter Lesson
4. 辩证层：承认 token 成本和概念搜索的局限，业界正走向混合方案

核心结论：代码场景下 RAG 的三个根本缺陷——embedding 对标识符失效、管线乘性准确率、索引时效性漂移——叠加架构哲学上的无状态原则，共同把 Claude Code 推向了 grep。

Chrome DevTools MCP 特点是让 AI 编码助手直接接管 Chrome，复用登录态 + 拿到原生 DevTools 数据。

1. 定位：基于 Puppeteer 的 MCP 服务器，暴露 26+ 工具给 AI（点击、填表、截图、性能 trace、网络请求）。
2. 核心优势：无需重新登录，可直连你当前 Chrome 会话；AI 能调起完整 DevTools 面板。
3. 三种连接模式：默认独立实例 / --autoConnect 复用会话 / --browser-url 远程调试端口。
4. 关键陷阱：远程调试端口无鉴权，同机任何应用都能连；MCP 客户端可读浏览器全部数据。