这些工作在目前主流的团队或者先进的个人项目中，是怎么具体化实践的。

回复 贝尔： 主流团队和成熟个人项目里，这套机制基本是按下面四步落地的： 1. 目录结构与渐进式加载（按需注入） 不会把所有说明塞进 System Prompt。主流做法（如 Claude Code、Pi、Cursor 等遵循的 Agent Skills 标准）是一个 Skill 一个独立目录，里面放核心的 SKILL.md、辅助脚本（scripts/）和模板。 启动时，框架只扫描各个 SKILL.md 顶部的 YAML frontmatter（只有 name 和一两句话的 description，注明触发场景），拼成极短的列表放进初始上下文。只有当模型判断当前任务命中某个 description 时，才调用 read_file 把完整的 SKILL.md 读进上下文，再按里面的步骤去调 bash 或 MCP。 2. 底座工具收敛 + 脚本化封装（Code over Tool） 先进项目都在砍专用 Tool 的数量。底层常驻的往往只有 bash、read、write、edit 这几个原子工具。 以前需要写十几个复杂 MCP 工具的业务逻辑，现在直接写成确定性的 Python 或 Shell 脚本放在 Skill 目录里。SKILL.md 只负责告诉模型：什么情况下用 bash 跑哪个脚本、传什么参数、报错怎么处理。这样既省了维护大量 Tool Schema 的开销，又利用了模型擅长写命令和读日志的优势。 3. 分层放置（对齐三级 Harness） 实际工程里不会把所有 Skill 混在一起，通常分三层挂载： 个人层（比如放在 ~/.claude/skills 或个人的 dotfiles 仓库）：放个人偏好的工作流、通用检索或写作习惯，跨项目复用。 Repo 层（放在项目根目录的.agents/skills 或.claude/skills）：跟着 Git 走，放当前仓库特有的数据库迁移流程、发版脚本、特殊架构约束，全组共享。 组织层：把公司内部的权限审批、私有平台接口封装成内部插件市场或统一分发仓库，按团队按需拉取。 4. 生命周期管理（从 badcase 生，随模型升级死） 真正跑得好的项目，Skill 不是一上来凭空设计的，而是从真实 badcase 里长出来的： 创建：平时先用原生模型干活，只有当某类任务反复踩同一个坑（比如总忘加某个编译参数、总调错内部接口顺序），才让模型自己把这次排障过程总结成一份 SKILL.md 存下来。 冲突治理：定期检查各个 Skill 的 description。如果两个 Skill 描述太像，模型会选错或漏调，要么合并，要么把触发边界写得极具体（明确写出“遇到 A 用这个，遇到 B 别用”）。 淘汰：每次换新一代基座模型（比如升到更强的 Coding 模型），拿之前积累的真实报错任务跑一遍回归测试——把某个旧 Skill 删掉看新模型能不能裸跑通过。能直接做对的，说明这个补丁已经被模型内化了，立刻删掉，给上下文减负。