多Agent设计与工程
最近在参加这个行动营，后续会结合课程学到的知识陆续更新～
AI编程范式转换
模型
模型的本质：无状态函数
大语言模型：每次调用都是独立，无记忆、无状态的
三个关键约束：无记忆、无决策、无行动
本质：模型是一个极其强大但完全被动的推理引擎
编排器
编排器的本质：有状态系统（Harness）
while true : 观察——>思考——>行动——>更新状态
三个核心能力（模型不具备的）
循环：持续运行，直到任务完成或用户中断
记忆：维护对话历史、项目上下文、工具调用结果
行动：读写文件、执行命令、调用API、与外部系统交互
openCode/ claude code/cursor 本质都是编排器，都是Harness
负责管理状态、调度模型、执行工具、维护上下文，提供权限系统和确保运行时安全
上下文管理
模型上下文窗口有限（200k tokens）
Harness的解决方案：自动压缩+重注入
Harness比模型更重要
同一个模型在不同Harness中的表现差距远大于不同模型在同一个harness中的差距。
调教Harness的能力 =真正的杠杆点
扩展补充下
RAG vs Claude Agentic Search 核心对比
小结
编程不再是写代码，而是写规范 + 验证结果
编程 = 设计意图 × 精确表达 × 验证产出
模型已经够强，差距在你能否把需求说清楚
80% 想清楚要什么，20% 让 AI 去实现
Agent = 推理 + 记忆 + 行动 + 各种工程护栏
Harness 比模型更重要，是你真正的杠杆
工具会过时，但工程思想不会
AI时代最稀缺的是不是会写代码的人，而是能够把问题定义好的人，能够知道要解决具体事情的人
目标比过程更为重要，过程完全可以托管给agent。
Memory工程
什么是Memory
AI的持久化记忆系统
工程思想：声明式配置优先
描述要什么而非怎么做，让Agent自己决定最优执行路径
可审计、可版本控制、可协作
从memory到规范驱动开发（SDD）
| 层级 | 文件 | 作用 |
| 项目规范 | AGENTS.md | 项目的技术栈、编码规范、架构约束 |
| 角色规范 | agents/*.md | 每个 Agent 的身份、权限、职责 |
| 能力规范 | skills/*/SKILL.md | 每个可复用技能的步骤和输入输出 |
agent.md的6个组成部分
项目概述— 一句话说清项目是什么、做什么（让 Agent 建立全局认知）
技术栈— 语言、框架、数据库、测试工具等（防止 Agent 推荐错误的技术）
编码规范— 命名规则、代码风格、禁止项（统一团队代码风格）
项目结构— 目录布局和职责（让 Agent 知道代码该放哪里）
工作流程— 提交规范、分支策略、CI/CD（与团队流程对齐）
特殊约束— 安全要求、性能要求、合规要求等（守住底线红线）
上下文管理策略：让Memory更高效
分层配置— 根目录 AGENTS.md 放通用规则，子目录放特定规则
保持精简— 控制在 500 行以内，太长反而稀释关键信息
优先级明确— 最重要的规则放最前面，Agent 注意力有衰减
定期维护— 随项目演进更新 Memory，过期规则及时清理
团队共建— Memory 文件纳入 Code Review 流程，团队共同维护
规则双向配置—正面的规则和负面（禁止）的规则需要明确
小结
👉 AGENTS.md = 项目的 “入职手册”
👉 Memory 三层：项目规范 → 角色规范 → 能力规范
👉 声明式配置优先：写 What, 不写 How
👉 Memory 在上下文压缩后会被重新注入 —— 持久生效的秘密
角色定义（Sub-Agents角色分工）
核心概念
Agent = 角色 + 权限 + 任务
隔离上下文、任务委派
为什么要角色分工
问题 1：上下文爆炸 — 一个 Agent 干所有事，Token 飙到 50K+，信息丢失
采集 30 条数据 + 逐条分析 + 去重入库 → 后面的指令被遗忘
问题 2：角色混乱 — AI 分不清现在该采集还是分析
采集时顺手改了文件，分析时编造了数据
问题 3：权限泄漏 — 没有边界，AI 什么都能做
本该只读的操作执行了写入，甚至跑了
rm -rf
问题 4：调试困难 — 出了问题不知道是哪个环节
结果不对，是采集错了？分析错了？还是整理错了？
Harness才是Agent，LLM只是推理引擎
反直觉真相：同一个 Claude 模型，换不同 Harness，能力天壤之别
Harness 五大机制：
① Agentic Loop — while (tool_call) { execute → feed_back → repeat }
② 工具权限图 — allowed-tools 白名单，系统级硬约束
③ 上下文压缩器 — 92% 窗口占用时自动压缩，CLAUDE.md 重新注入
④ Sub-Agent 隔离边界 — 独立 context window + 结果压缩回传
⑤ 实时转向队列 — 用户可在 Agent 执行中途注入新指令
工程启示：
"如果你还在纠结用哪个模型，你问错了问题。""10 倍差距来自 Harness：怎么管理上下文、约束工具、隔离执行。""模型是大宗商品，Harness 才是产品。"
Agent SDK — 把 Claude Code 的 Harness 抽出来给你用
pip install claude-agent-sdk / npm i @anthropic-ai/claude-agent-sdk
上下文隔离 = 对注意力的分治算法
经典分治：大问题 → 分成小问题 → 分别求解 → 合并结果
Sub-Agent 隔离：大上下文 → 分成小上下文 → 分别推理 → 合并摘要
注意力压缩比实测：
子 Agent 内部消耗 50,000 tokens 探索 → 返回 1,500 tokens 摘要压缩比 = 33:1，主 Agent 注意力零损耗
Google Research 量化验证（arXiv:2512.08296, 2025.12）：
独立多 Agent（无隔离） → 错误放大 17.2 倍集中式协调（有隔离） → 错误控制在 4.4 倍并行任务性能提升 +80.9%，但串行推理反而退化 39-70%
Token 经济学：
单 Agent 6 轮对话：~180,000 input tokens三 Agent 流水线：~138,000 input tokens（省 23%+）
决策法则：
上下文 < 5K → 别分，SP 开销不划算中间输出 > 500 tokens → 该分，注意力已被污染
实战
@mention 和 Task 工具委派 Sub-Agent 有什么区别？什么时候用哪种？
两种方式触发：
@analyzer ... — 带上 analyzer 的角色定义读了 knowledge/raw/，分析后直接输出 JSON（没写文件）
@organizer ... — 带上 organizer 的角色定义，执行了 Write 把 10 个文件写入 knowledge/articles/
跟之前 @collector 的问题一样 —@mention 本质是角色提示注入，工具权限没有被真正切掉。分析环节本该只读，但我在 @analyzer 时其实也有 Write 能力（只是没调用）；整理环节 @organizer 的 WebFetch 禁不掉（只是没用到）。
核心收获
@mention快速切换角色，适合简单任务
Task 工具创建隔离上下文，适合复杂独立任务
Agent 之间通过文件协作，不通过上下文共享
SKILL
skill各字段含义![]()
Skill不是代码，是知识。是方法论，框架。
Skill vs Sub-Agents vs context:fork 三者关系
Sub-Agent — 独立执行上下文，需要手动调度，知识在对话中（临时的）
Skill — 持久化知识包，AI 自动触发，知识在文件中（永久的）
Skill + context:fork — 两者合体：持久知识 + 自动创建临时子代理
--- name: 产品文档校对 trigger: ["校对文档", "文案检查", "PRD校验"] context:fork: true --- # 校对SOP1. 统一公司专属术语、固定格式
怎么选？
→ 需要 AI 自己判断何时用 → Skill
→ 需要隔离执行环境 → Sub-Agent
→ 需要持久知识 + 隔离执行 → Skill + context:fork
类比:
Sub-Agent = 公司内部专家（你要给他交代细节）
Skill = 团队内部的 SOP 手册（写一次，所有人都能用）
Skill + fork = SOP 手册 + 临时派人去独立执行
Superpowers
官方标准技能包，适用于claude code 等工具
git仓库地址：https://github.com/obra/superpowers/