最近在参加这个行动营，后续会结合课程学到的知识陆续更新～

AI编程范式转换

模型

模型的本质：无状态函数

大语言模型：每次调用都是独立，无记忆、无状态的

三个关键约束：无记忆、无决策、无行动

本质：模型是一个极其强大但完全被动的推理引擎

编排器

编排器的本质：有状态系统（Harness）

while true : 观察——>思考——>行动——>更新状态

三个核心能力（模型不具备的）

循环：持续运行，直到任务完成或用户中断

记忆：维护对话历史、项目上下文、工具调用结果

行动：读写文件、执行命令、调用API、与外部系统交互

openCode/ claude code/cursor 本质都是编排器，都是Harness

负责管理状态、调度模型、执行工具、维护上下文，提供权限系统和确保运行时安全

上下文管理

模型上下文窗口有限（200k tokens）

Harness的解决方案：自动压缩+重注入

Harness比模型更重要

同一个模型在不同Harness中的表现差距远大于不同模型在同一个harness中的差距。

调教Harness的能力 =真正的杠杆点

扩展补充下

RAG vs Claude Agentic Search 核心对比

小结

1. 编程不再是写代码，而是写规范 + 验证结果

2. 编程 = 设计意图 × 精确表达 × 验证产出

3. 模型已经够强，差距在你能否把需求说清楚

4. 80% 想清楚要什么，20% 让 AI 去实现

5. Agent = 推理 + 记忆 + 行动 + 各种工程护栏

6. Harness 比模型更重要，是你真正的杠杆

7. 工具会过时，但工程思想不会

AI时代最稀缺的是不是会写代码的人，而是能够把问题定义好的人，能够知道要解决具体事情的人

目标比过程更为重要，过程完全可以托管给agent。

Memory工程

什么是Memory

AI的持久化记忆系统

工程思想：声明式配置优先

描述要什么而非怎么做，让Agent自己决定最优执行路径

可审计、可版本控制、可协作

从memory到规范驱动开发（SDD）

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 有什么区别？什么时候用哪种？

两种方式触发：

1. @analyzer ... — 带上 analyzer 的角色定义读了 knowledge/raw/，分析后直接输出 JSON（没写文件）

2. @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/

总结