Context Engineering 与 Agent 设计¶
一句话说明:Context Engineering(上下文工程)是比 Prompt Engineering 更高一层的技能——不只是"怎么问 AI",而是"给 AI 喂什么信息",让它在有限的上下文窗口里表现最好。
目录¶
- 什么是 Context Engineering
- Context Engineering vs Prompt Engineering
- Context 的六大组成部分
- Agent 设计原则
- AGENTS.md / CLAUDE.md 最佳实践
- 实操教程:设计一个生信分析 Agent 的完整 Context
- 面试怎么答
- 速查表
- 延伸资源
1. 什么是 Context Engineering¶
1.1 定义¶
Context Engineering(上下文工程)这个术语在 2025 年中由 Shopify CEO Tobi Lutke 提出,随后被 AI 领域重量级人物 Andrej Karpathy(前 Tesla AI 总监、OpenAI 联合创始人)公开背书推广。
Karpathy 的原话:
"Context engineering is the delicate art and science of filling the context window with just the right information for the next step."
——上下文工程是一门精细的艺术与科学:在上下文窗口中填入恰好正确的信息,以支撑下一步操作。
1.2 白话解释¶
想象你请了一位超级聪明但失忆的专家来帮你干活(这就是 LLM)。每次他开始工作前,你要把所有相关资料塞进一个有限大小的文件夹(上下文窗口,context window)交给他。
- Prompt Engineering:关注"你怎么跟专家说话"——措辞、语气、指令格式
- Context Engineering:关注"你往文件夹里放什么资料"——哪些背景知识、参考案例、工具手册、历史记录要一起给他
关键限制:文件夹大小有限(如 Claude 的 200K tokens,约 15 万字),塞太多会导致专家"看花眼"、忽略重要信息。所以不是越多越好,而是要精准投放。
1.3 为什么突然火了¶
| 时间 | 事件 |
|---|---|
| 2023 年前 | 主流概念是"Prompt Engineering"——写好提示词就行 |
| 2024 年 | AI Agent 兴起,光写提示词不够了,需要系统化地管理上下文 |
| 2025 年 6 月 | Tobi Lutke 和 Karpathy 公开推动"Context Engineering"概念 |
| 2025-2026 年 | Anthropic 发布 Claude Code 最佳实践,核心就是上下文管理 |
2. Context Engineering vs Prompt Engineering¶
2.1 核心区别¶
| 维度 | Prompt Engineering | Context Engineering |
|---|---|---|
| 白话 | 怎么问问题 | 给什么资料 |
| 关注点 | 指令措辞、格式、角色设定 | 整个上下文窗口的信息组合 |
| 比喻 | 跟专家说话的技巧 | 给专家准备的整套工作资料 |
| 范围 | 单次对话优化 | 系统级信息架构设计 |
| 技术栈 | 手写 prompt、模板 | RAG、工具调用、记忆系统、CLAUDE.md |
| 难度 | 入门容易 | 需要系统设计思维 |
2.2 一个生信例子¶
Prompt Engineering 阶段(你只管怎么问):
Context Engineering 阶段(你管整个信息环境):
System Prompt: 你是肠道微生物组分析专家,擅长 QIIME2 和 LEfSe...
Few-shot: 这是一个类似分析的成功案例 [附上参考输出格式]
RAG 检索: 从知识库找到 3 篇最相关的 T2D 肠道菌群文献摘要
工具输出: QIIME2 的 alpha diversity 计算结果 [数据表]
用户画像: 用户是生信初学者,需要详细解释每一步
记忆: 上次对话中用户提到数据是 V3-V4 区域,Illumina PE250
后者的效果显然远超前者,因为 AI 获得了充分且精准的上下文。
3. Context 的六大组成部分¶
根据 Anthropic 官方文档和行业实践,一个完整的 Context 由以下六层组成:
3.1 System Prompt(系统提示词)¶
白话:给 AI 一个"人设",告诉它是谁、该怎么做事。
# 系统提示词示例
system_prompt = """
你是一个宏基因组分析专家。
# 你的能力
- 熟悉 Kraken2、MetaPhlAn4、HUMAnN3 等工具
- 精通 16S 和 shotgun metagenomics 分析流程
# 你的行为准则
- 所有代码加中文注释
- 先解释原理,再给代码
- 遇到不确定的参数,明确说明并给推荐值
"""
3.2 Few-shot Examples(少量示例)¶
白话:给 AI 看几个"标准答案",让它模仿着做。
# few-shot 示例:教 AI 怎么解读 alpha 多样性结果
few_shot = """
## 输入示例
Shannon 指数:T2D组 = 3.2 ± 0.8,健康组 = 4.5 ± 0.6,p = 0.003
## 期望输出
### Alpha 多样性分析结果
- **Shannon 指数**显示 T2D 组(3.2 ± 0.8)显著低于健康组(4.5 ± 0.6)
- **统计检验**:Wilcoxon 秩和检验 p = 0.003(< 0.05,差异显著)
- **生物学意义**:T2D 患者肠道菌群多样性降低,这与已有文献一致
(Qin et al., 2012, Nature)
"""
3.3 RAG 检索结果(Retrieval-Augmented Generation)¶
白话:AI 自己不知道的最新知识,从外部数据库实时搜索后塞进上下文。
# RAG 流程伪代码
def get_context_from_rag(user_query):
# 1. 把用户问题转成向量(embedding)
query_vector = embed(user_query) # 文本 → 数字向量
# 2. 从向量数据库搜索最相关的文档片段
relevant_docs = vector_db.search( # 搜最近邻
query_vector,
top_k=5 # 取最相关的5段
)
# 3. 把搜到的文档塞进 context
context = "\n".join([doc.text for doc in relevant_docs])
return context
生信场景的 RAG 应用: - 从 PubMed 检索最新 T2D 菌群研究 - 从内部知识库检索工具安装教程 - 从 NCBI Taxonomy 检索菌种分类信息
3.4 Tool Output(工具输出)¶
白话:AI 调用外部工具(跑代码、查数据库、搜网页)后得到的结果。
这是 Agent 的核心能力。Anthropic 在 "Building Effective Agents" 中指出:
"The basic building block of agentic systems is an LLM enhanced with augmentations such as retrieval, tools, and memory."
# 工具定义示例(MCP 协议格式)
tools = [
{
"name": "run_kraken2", # 工具名
"description": "对 FASTQ 文件进行物种注释", # 工具描述(很关键!)
"parameters": { # 参数定义
"input_fastq": "输入的测序文件路径",
"database": "Kraken2 数据库路径",
"confidence": "置信度阈值,默认 0.2"
}
}
]
# AI 调用工具后,工具输出会自动进入 context
# 例如 Kraken2 跑完后返回:
# "总 reads: 1000000, 已分类: 650000 (65%), 未分类: 350000 (35%)"
3.5 Memory(记忆)¶
白话:跨对话记住用户说过的重要信息,下次不用重复。
记忆分两种: - 短期记忆:当前对话的历史消息(自动在 context 中) - 长期记忆:跨对话持久化存储(需要额外实现)
# 长期记忆示例
memory = {
"user_info": {
"name": "[用户]",
"level": "[届别]毕业生,生信初学者",
"project": "T2D 肠道菌群宏基因组分析"
},
"preferences": {
"language": "中文",
"code_style": "每行加中文注释",
"conda_envs": ["ml_env", "bioinfo", "qc_env"]
},
"history": [
"上次讨论了 Kraken2 数据库构建",
"已完成 FastQC 质控步骤"
]
}
3.6 User Profile(用户画像)¶
白话:根据用户是谁,动态调整回答的深度和风格。
| 用户类型 | Context 策略 |
|---|---|
| 生信新手 | 多给背景解释、白话类比、完整代码 |
| 资深研究员 | 直接给关键参数、省略基础解释 |
| 面试候选人 | 侧重原理和"为什么",不只是"怎么做" |
4. Agent 设计原则¶
4.1 什么是 Agent¶
根据 Anthropic 官方定义:
- Workflow(工作流):LLM 按预设代码路径执行,人来编排
- Agent(智能体):LLM 自主决定执行路径和工具调用,动态规划
白话:Workflow 是"流水线工人",Agent 是"独立接单的项目经理"。
4.2 Anthropic 的 Agent 设计模式¶
Anthropic 在 "Building Effective Agents" 中总结了五种实用模式:
| 模式 | 白话 | 适用场景 |
|---|---|---|
| Prompt Chaining(提示链) | 一步步来,上一步的输出喂给下一步 | 任务可以明确分步的情况 |
| Routing(路由) | 先分类,再分发给专门的处理器 | 客服分类、难度分级 |
| Parallelization(并行) | 多个 LLM 同时干不同/相同的活 | 多角度审查代码 |
| Orchestrator-Workers(编排者-工人) | 一个 LLM 当老板派活,其他 LLM 干活 | 复杂编码任务 |
| Evaluator-Optimizer(评审-优化) | 一个生成,一个评审,循环改进 | 翻译、文案打磨 |
4.3 Agent 设计的四大核心原则¶
原则一:Tool 选择——精心设计工具接口¶
Anthropic 强调:
"We actually spent more time optimizing our tools than the overall prompt."
生信工具设计要点:
# 好的工具定义——清晰、有边界、参数名自解释
{
"name": "run_diversity_analysis",
"description": "计算样本的 alpha 多样性指标(Shannon、Simpson、Chao1)。"
"输入必须是 QIIME2 的 FeatureTable[Frequency] 格式的 .qza 文件。"
"输出为 TSV 表格和箱线图。",
"parameters": {
"feature_table": {
"type": "string",
"description": "QIIME2 feature table 的绝对路径,如 /data/table.qza"
# 注意:Anthropic 建议用绝对路径,防止 Agent 在不同目录下迷路
},
"metrics": {
"type": "array",
"description": "要计算的指标列表",
"default": ["shannon", "simpson", "chao1"]
}
}
}
原则二:观察空间设计——让 Agent 看到关键反馈¶
Agent 每一步都需要从环境获得"真实反馈"(ground truth),才能判断是否走对了路。
# 差的观察空间:只返回"成功/失败"
tool_output = {"status": "success"}
# 好的观察空间:返回可验证的详细信息
tool_output = {
"status": "success",
"summary": {
"total_reads": 1000000, # 总 reads 数
"classified": 650000, # 已分类数
"classified_pct": 65.0, # 分类率
"top_species": [ # Top 5 物种
{"name": "Bacteroides vulgatus", "pct": 12.3},
{"name": "Faecalibacterium prausnitzii", "pct": 8.7}
]
},
"warnings": [ # 潜在问题提醒
"分类率低于 70%,建议检查数据库版本是否匹配"
],
"output_files": ["/results/kraken2_report.txt"]
}
原则三:错误恢复——Agent 遇到报错不能直接崩¶
# Agent 的错误处理策略
error_handling = """
当工具调用失败时:
1. 首先读取错误信息,判断原因
2. 如果是参数错误 → 修正参数重试(最多 3 次)
3. 如果是依赖缺失 → 告知用户需要安装什么
4. 如果是数据格式问题 → 尝试格式转换
5. 如果重试 3 次仍失败 → 暂停并报告给用户
"""
原则四:上下文窗口管理——最核心的资源约束¶
Anthropic 在 Claude Code 最佳实践中明确指出:
"Most best practices are based on one constraint: Claude's context window fills up fast, and performance degrades as it fills."
管理策略:
| 策略 | 做法 | 白话 |
|---|---|---|
| 及时清理 | 不相关任务间 /clear | 做完一件事就清空桌面 |
| 子代理 | 让子 Agent 探索代码库,只汇报摘要 | 派侦察兵去看,回来报告要点 |
| 压缩历史 | 自动或手动 /compact 压缩对话 | 把厚笔记浓缩成摘要 |
| 选择性读取 | 只读相关文件的关键部分 | 不翻整本书,只查目录和重点章节 |
5. AGENTS.md / CLAUDE.md 最佳实践¶
5.1 什么是 CLAUDE.md¶
CLAUDE.md 是 Claude Code 启动时自动读取的配置文件,相当于"项目说明书"。它直接决定了 Agent 每次对话的初始上下文。
和你直接相关的应用:该项目根目录下的 CLAUDE.md 就是你在用的。
5.2 写好 CLAUDE.md 的原则¶
根据 Anthropic 官方最佳实践文档:
该写什么:
| 类别 | 示例 |
|---|---|
| AI 猜不到的命令 | conda activate bioinfo 然后 snakemake --cores 4 |
| 非标准的代码风格 | "所有 Python 代码每行加中文注释" |
| 测试指令 | pytest tests/ -v --cov=src |
| 项目特殊约定 | "conda 环境:ml_env、bioinfo、qc_env" |
| 常见坑 | "kraken2 数据库路径必须用绝对路径" |
不该写什么:
| 类别 | 原因 |
|---|---|
| AI 能从代码推断的东西 | 浪费上下文窗口 |
| 标准语言规范 | AI 已经知道 PEP8 |
| 详细 API 文档 | 给链接就行,别全文复制 |
| 频繁变化的信息 | 每次变都要改 CLAUDE.md |
| "写干净的代码" | 太泛,没有实际指导意义 |
5.3 实际 CLAUDE.md 示例¶
# 面试准备项目
## 用户背景
- [用户],[届别]毕业生,准备生信工程师面试
- 英语和编程基础薄弱,需要中文解释 + 白话类比
## 项目结构
- project/ - 14天学习计划的实操项目
- knowledge_base/ - 知识库(22篇基础 + 24篇工具教程)
## 操作规则
- 安装任何软件/包之前必须先询问用户
- 所有代码每行加中文注释
- conda 环境:ml_env(机器学习)、bioinfo(生信分析)
## 知识库写作格式
- 白话解释 + 安装配置 + 代码实操 + 常见报错 + 速查表
- 每篇 3000-5000 字
5.4 CLAUDE.md 的层级结构¶
| 位置 | 作用 | 优先级 |
|---|---|---|
~/.claude/CLAUDE.md | 个人全局配置 | 最低 |
项目根目录/CLAUDE.md | 团队共享的项目配置 | 中 |
项目根目录/CLAUDE.local.md | 个人项目配置(不提交 git) | 高 |
子目录/CLAUDE.md | 子模块专属配置(按需加载) | 按需 |
5.5 AGENTS.md 的作用¶
AGENTS.md 是一些 AI 代码编辑器(如 Cursor、Windsurf、OpenCode)使用的类似机制,功能和 CLAUDE.md 等价——给 Agent 提供项目级别的持久上下文。
6. 实操教程:设计一个生信分析 Agent 的完整 Context¶
6.1 场景定义¶
设计一个能自主完成宏基因组分析的 Agent,从原始 FASTQ 到最终报告。
6.2 Context 分层设计¶
┌─────────────────────────────────────────────┐
│ Layer 1: System Prompt(角色定义) │
│ "你是宏基因组分析 Agent,精通以下流程..." │
├─────────────────────────────────────────────┤
│ Layer 2: CLAUDE.md(项目规则) │
│ "conda 环境、文件路径、输出格式要求..." │
├─────────────────────────────────────────────┤
│ Layer 3: Tools(可用工具) │
│ FastQC, Trimmomatic, Kraken2, HUMAnN3... │
├─────────────────────────────────────────────┤
│ Layer 4: RAG(知识库检索) │
│ 按需检索工具文档、参考文献、报错解决方案 │
├─────────────────────────────────────────────┤
│ Layer 5: Memory(记忆) │
│ 用户偏好、已完成步骤、中间结果 │
├─────────────────────────────────────────────┤
│ Layer 6: Tool Output(实时反馈) │
│ 每步分析的输出结果,用于决定下一步 │
└─────────────────────────────────────────────┘
6.3 完整 Context 代码示例¶
# ============================
# 生信分析 Agent 的完整 Context 设计
# ============================
# --- Layer 1: System Prompt ---
system_prompt = """
你是一个专业的宏基因组数据分析 Agent。
## 你的能力
- 执行完整的 shotgun metagenomics 分析流程
- 从原始 FASTQ → 质控 → 物种注释 → 功能注释 → 统计分析 → 报告
## 分析流程(按顺序执行)
1. FastQC 质控检查
2. Trimmomatic / fastp 去接头和低质量碱基
3. Kraken2 + Bracken 物种注释
4. HUMAnN3 功能通路分析
5. Alpha/Beta 多样性分析
6. LEfSe 差异分析
7. 生成 HTML 报告
## 行为准则
- 每个步骤执行后,检查输出文件是否存在且非空
- 如果某步骤失败,先尝试修复,3 次失败后报告用户
- 所有中间结果保存到 results/ 目录
- 关键参数使用前先确认
"""
# --- Layer 2: 工具定义(Tools)---
tools = [
{
"name": "run_fastqc", # 质控检查工具
"description": "对 FASTQ 文件运行 FastQC 质量检查。"
"输出 HTML 报告和 ZIP 文件到指定目录。",
"parameters": {
"input_files": "FASTQ 文件路径列表(绝对路径)",
"output_dir": "输出目录(绝对路径)",
"threads": "线程数,默认 4"
}
},
{
"name": "run_kraken2", # 物种注释工具
"description": "使用 Kraken2 对 reads 进行物种分类注释。"
"需要预先构建好的 Kraken2 数据库。"
"confidence 建议设为 0.2 以平衡灵敏度和特异性。",
"parameters": {
"input_r1": "正向 reads 文件路径",
"input_r2": "反向 reads 文件路径",
"database": "Kraken2 数据库绝对路径",
"confidence": "置信度阈值,默认 0.2",
"output_dir": "结果输出目录"
}
},
{
"name": "run_statistical_test", # 统计检验工具
"description": "对两组样本进行统计检验(Wilcoxon/Mann-Whitney U)。"
"输入为 TSV 表格,需包含 group 列。",
"parameters": {
"input_table": "输入数据表路径",
"group_column": "分组列名",
"test_method": "检验方法:wilcoxon 或 mannwhitney",
"p_threshold": "显著性阈值,默认 0.05"
}
}
]
# --- Layer 3: Few-shot Examples ---
few_shot_examples = """
## 示例:解读 Kraken2 输出
### 输入
Kraken2 报告显示:
- 分类率:72%
- Top 物种:Bacteroides vulgatus (15%), F. prausnitzii (8%)
### 期望输出格式
#### Kraken2 物种注释结果
- **总体分类率**:72%(正常范围 60-80%)
- **优势物种**:
1. *Bacteroides vulgatus* (15%) — 拟杆菌属,肠道常见厌氧菌
2. *Faecalibacterium prausnitzii* (8%) — 产丁酸菌,抗炎标志物
- **提示**:分类率在正常范围内,无需调整参数
"""
# --- Layer 4: Memory(跨对话记忆)---
memory = {
"project": "T2D 肠道菌群宏基因组分析",
"completed_steps": ["FastQC", "Trimmomatic"], # 已完成的步骤
"data_info": {
"platform": "Illumina NovaSeq 6000",
"read_length": "PE150",
"sample_count": 30, # 15 T2D + 15 健康对照
"region": "shotgun whole genome"
},
"issues_encountered": [
"Kraken2 数据库下载中断过一次,重新下载解决"
]
}
6.4 Agent 执行流程¶
用户输入: "分析这批宏基因组数据"
│
▼
Agent 读取 Context(System Prompt + CLAUDE.md + Memory)
│
▼
Agent 制定计划: "需要执行 7 个步骤"
│
▼
Step 1: 调用 run_fastqc → 检查输出 → ✅ 通过
│
▼
Step 2: 调用 run_trimmomatic → 检查输出 → ✅ 通过
│
▼
Step 3: 调用 run_kraken2 → 检查输出 → ⚠️ 分类率只有 45%
│
▼
Agent 判断: "分类率异常低,可能是数据库不匹配"
│
▼
Agent 从 RAG 检索: "Kraken2 分类率低的常见原因"
│
▼
Agent 修复: 切换到更大的数据库 → 重跑 → ✅ 分类率 72%
│
▼
继续后续步骤...
7. 面试怎么答¶
Q1: 什么是 Context Engineering?和 Prompt Engineering 有什么区别?¶
参考回答:Context Engineering 是 2025 年由 Shopify CEO Tobi Lutke 提出、Andrej Karpathy 推广的概念。Prompt Engineering 关注"怎么写提示词"——措辞、格式、角色设定;Context Engineering 关注更高层面——"往上下文窗口里放什么信息"。它包括 System Prompt、Few-shot 示例、RAG 检索结果、工具输出、记忆和用户画像六个层次。打个比方,Prompt Engineering 是"怎么跟专家说话",Context Engineering 是"给专家准备什么工作资料"。在实际 Agent 开发中,Context Engineering 的重要性远超单纯的 Prompt 优化。
Q2: 如果让你设计一个生信分析 Agent,你会怎么设计它的上下文?¶
参考回答:我会分六层设计。第一层是 System Prompt,定义 Agent 的角色(宏基因组分析专家)和行为准则(每步检查输出、失败自动重试)。第二层是项目配置文件 CLAUDE.md,写清 conda 环境名、数据路径、输出格式要求。第三层是工具定义,把 FastQC、Kraken2、HUMAnN3 等封装成标准工具接口,每个工具有清晰的参数描述和使用示例。第四层是 RAG 检索,按需从知识库检索工具文档和报错解决方案。第五层是记忆,记录用户偏好和已完成步骤。第六层是实时工具输出,Agent 根据每步反馈决定下一步动作。关键是上下文窗口有限,要精准投放信息,不能把所有文档都塞进去。
Q3: Agent 和传统的自动化脚本(如 Snakemake pipeline)有什么区别?¶
参考回答:传统 pipeline 如 Snakemake 是 Workflow 模式——执行路径是预定义的,遇到错误直接终止。Agent 是自主决策模式——它能根据中间结果动态调整策略。比如 Kraken2 分类率异常低,Snakemake 只会报错停止,而 Agent 能自动分析原因(可能是数据库版本不匹配),尝试切换数据库重跑。Agent 的核心优势是灵活性和自我纠错能力。但 Agent 也有成本更高、可能出错累积的缺点。Anthropic 的建议是:先用简单方案,只在简单方案不够时才上 Agent。
Q4: CLAUDE.md / AGENTS.md 的作用是什么?写的时候有什么注意事项?¶
参考回答:CLAUDE.md 是 AI 编码 Agent 启动时自动读取的项目配置文件,为每次对话提供持久的项目上下文。核心原则是"写 AI 猜不到的东西"——特殊的命令、非标准的代码规范、环境配置。不该写 AI 能自己推断的内容,比如标准语言规范,也不该写太长,因为文件太长 Agent 会忽略重要规则。Anthropic 建议像维护代码一样维护 CLAUDE.md:定期修剪、观察 Agent 行为变化、团队协作提交到 git。
Q5: 在 Agent 开发中,怎么管理上下文窗口?¶
参考回答:上下文窗口是 Agent 最核心的资源约束。Anthropic 在最佳实践中明确说"大多数最佳实践都基于一个约束——上下文窗口填满得很快,填满后性能下降"。管理策略有四个:一是任务间清理,不相关任务之间清空上下文;二是用子代理做探索,让子代理在独立的上下文里搜索代码库,只汇报摘要;三是压缩历史,把长对话浓缩成关键决策和代码摘要;四是选择性读取,只读相关文件的关键部分,不要整个文件都塞进去。核心原则是"不是信息越多越好,而是精准投放"。
8. 速查表¶
Context Engineering 六层结构¶
┌──────────────────────────────────────────────┐
│ 层级 │ 内容 │ 动态性 │
├──────────────────────────────────────────────┤
│ System Prompt │ 角色和规则 │ 静态 │
│ Few-shot │ 参考示例 │ 半静态 │
│ RAG │ 检索知识 │ 动态 │
│ Tool Output │ 工具结果 │ 实时 │
│ Memory │ 历史记忆 │ 持久 │
│ User Profile │ 用户画像 │ 半静态 │
└──────────────────────────────────────────────┘
Agent 五大设计模式速查¶
| 模式 | 一句话 | 何时用 |
|---|---|---|
| Prompt Chaining | 串行流水线 | 任务可明确分步 |
| Routing | 先分类再处理 | 输入类型多样 |
| Parallelization | 多路并行 | 需要多角度或加速 |
| Orchestrator-Workers | 老板派活 | 复杂任务不确定子任务 |
| Evaluator-Optimizer | 写→评→改循环 | 有明确质量标准 |
CLAUDE.md 检查清单¶
✅ 该写:
□ AI 猜不到的 bash 命令
□ 非标准代码风格
□ 测试命令和运行方式
□ 项目特殊约定(分支命名、PR 格式)
□ 环境变量和依赖
❌ 不该写:
□ AI 能从代码推断的内容
□ 标准语言规范
□ 详细 API 文档(给链接)
□ "写干净的代码"之类的废话
上下文窗口管理策略¶
问题 → 解决方案
───────────────────────────────────
上下文快满了 → /compact 压缩或 /clear 清空
不相关内容混在一起 → 任务间 /clear
探索代码库占太多上下文 → 用子代理探索,汇报摘要
修了好几次还没修好 → /clear 后用更好的初始 prompt
CLAUDE.md 太长被忽略 → 精简,只保留必要规则
9. 延伸资源¶
必读文档¶
| 资源 | 说明 | 链接 |
|---|---|---|
| Anthropic - Building Effective Agents | Agent 设计的权威指南 | anthropic.com/engineering/building-effective-agents |
| Anthropic - Claude Code Best Practices | 上下文管理最佳实践 | code.claude.com/docs/en/best-practices |
| Simon Willison - Context Engineering | Context Engineering 概念科普 | simonwillison.net/2025/Jun/27/context-engineering/ |
关键人物¶
| 人物 | 贡献 |
|---|---|
| Andrej Karpathy | 前 Tesla AI 总监,推广 Context Engineering 概念 |
| Tobi Lutke | Shopify CEO,首次公开使用 Context Engineering 术语 |
| Erik S. & Barry Zhang | Anthropic 工程师,撰写 Building Effective Agents |
推荐学习路径¶
入门:读 Simon Willison 的科普文章(10 分钟)
↓
进阶:读 Anthropic 的 Building Effective Agents(30 分钟)
↓
实践:写好自己项目的 CLAUDE.md(30 分钟)
↓
深入:读 Claude Code Best Practices,优化 Agent 配置(1 小时)
↓
应用:设计自己领域的 Agent(如生信分析 Agent)
相关知识库文档¶
- 知识库2-04: AI Agent 概念与架构
- 知识库2-27: Claude Code 终端 AI 编码助手
- 知识库2-56: AI Agent 实战 - CrewAI 多 Agent 协作
最后更新:2026-05-03 信息来源:Anthropic 官方文档、Simon Willison 博客、Andrej Karpathy 公开发言 字数:约 4500 字