# Agent Design

> AI系统设计核心方法论（基于斯坦福CS230 Beyond LLM）。当用户涉及以下场景时必须启用：设计AI系统架构、Prompt工程优化、RAG系统设计、Agent工作流设计、多Agent编排、Eval评估体系搭建、AI性能优化、系统从0到1规划。关键词触发：Agent设计、系统设计、Prompt优化、RAG、Eval、多智能体、工作流设计、AI架构、性能优化、提示链、Few-Shot、HyDE。这是曲率团队2026上半年的核心指导思想，覆盖 Prompt→微调→RAG→Agent→多Agent→Eval 完整链路。

- **Type:** Skill
- **Install:** `agentstack add skill-daknniel0881-png-agent-design-skill-agent-design-skill`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [daknniel0881-png](https://agentstack.voostack.com/s/daknniel0881-png)
- **Installs:** 0
- **Category:** [AI & ML](https://agentstack.voostack.com/c/ai-and-ml)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [daknniel0881-png](https://github.com/daknniel0881-png)
- **Source:** https://github.com/daknniel0881-png/agent-design-skill

## Install

```sh
agentstack add skill-daknniel0881-png-agent-design-skill-agent-design-skill
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# AI 系统设计方法论

> 基于斯坦福 CS230 Beyond LLM 核心思想，曲率团队 2026 上半年核心指导思想。
> 核心一句话：**模型不是瓶颈，工程手段才是。同一个模型，通过更好的 Prompt、RAG、Agent 工作流，性能能大幅提升。**

## 何时使用本 Skill

- 设计任何 AI 系统架构时
- 优化 Prompt / RAG / Agent 工作流时
- 搭建 Eval 评估体系时
- 为客户规划 AI 落地路径时
- 做多 Agent 编排设计时
- 任何涉及"怎么让 AI 干得更好"的问题

## 核心框架：AI 性能优化双轴

```
纵轴（工程增强）：Prompt → RAG → Agent → 多Agent
                    ↑ 本 Skill 的主战场
横轴（模型升级）：GPT-3.5 → GPT-4 → Claude 4 → ...
```

**决策原则**：先穷尽纵轴（工程增强），再考虑横轴（换模型）。换模型是最后手段。

与曲率现有体系的对应：
- 工程增强 > 换模型 = Harness 工程的核心论点（同模型换 Harness，52.8%→66.5%）
- 先确定性后模糊性 = Harness 工程的实操原则

---

## 模块1：LLM 的 6 个天生短板 + 工程解法

在设计任何 AI 系统之前，先确认你要解决的是哪个短板，再选对应的工程手段。

| # | 短板 | 具体表现 | 工程解法 | 曲率体系对应 |
|---|------|---------|---------|-------------|
| 1 | 领域知识缺失 | 农业病虫害、小众医疗等垂直领域答不好 | RAG + 领域文档库 | 知识库检索 |
| 2 | 信息过时 | 训练数据有截止日期，不知最新趋势 | RAG 实时更新 + 工具调用外部 API | MCP 集成 |
| 3 | 难以控制 | 输出有偏见、说不该说的话（Tay 事件） | Harness 约束 + Hook 物理拦截 + 护栏 | 三层评估体系 |
| 4 | 上下文有限 | 最好的模型≈两本书，企业文档远超此量 | 分块检索 + 记忆分层（工作/归档） | 记忆管理体系 |
| 5 | 幻觉问题 | 编造假论文、假数据，一本正经地胡说 | RAG 来源标注 + Eval 幻觉检测 | Eval 层 |
| 6 | 缺乏来源追溯 | 给答案但不说从哪来，法律/医疗不可用 | RAG 溯源到页码/章节 | 知识库引用 |

**操作步骤**：
1. 拿到需求后，先对照这 6 个短板逐一检查
2. 确认需求命中哪几个短板
3. 从对应的工程解法列中选择技术方案
4. 如果命中 3 个以上短板，大概率需要 Agent 工作流而非单步 Prompt

---

## 模块2：Prompt 工程完整技术栈

按复杂度从低到高排列，**先用简单的，不够再升级**。

### 2.1 基础四要素

每个 Prompt 必须回答四个问题：

| 要素 | 问题 | 示例 |
|------|------|------|
| 受众 | 给谁看的？ | "面向政策制定者" |
| 格式 | 什么格式？ | "总结为5个要点" |
| 聚焦 | 关注什么？ | "重点讲关键发现和影响" |
| 长度 | 全文多长？ | "每个要点不超过2句话" |

**三档样本**：

**好的 Prompt**（四要素齐全）：
```
将这篇10页的可再生能源论文总结为5个要点，面向政策制定者，重点讲关键发现及其对政策的影响。每个要点不超过2句话。
```
为什么好：受众明确（政策制定者→决定了语言风格和深度）、格式具体（5个要点→约束了结构）、聚焦清晰（关键发现和影响→排除了方法论等细节）、长度可控（2句话→避免废话）。

**中规中矩的 Prompt**（有格式但缺受众和聚焦）：
```
把这篇论文总结成5个要点。
```
差在哪：模型不知道给谁看，会默认写得很学术；不知道聚焦什么，可能把方法论、局限性都塞进来。

**差的 Prompt**（四要素全缺）：
```
帮我总结这个文档。
```
踩了什么坑：完全开放，模型只能猜。长度不可控、风格不确定、重点可能跑偏。

### 2.2 角色扮演

在 System Prompt 中设定人设。

**操作步骤**：
1. 确定任务所需的专业身份（如"资深可再生能源政策顾问"）
2. 补充上下文场景（如"正在为联合国气候峰会准备发言"）
3. 写入 System Prompt 的第一行

**注意**：角色扮演对简单任务收益不大，对需要特定专业视角的复杂任务效果显著。

### 2.3 少样本学习（Few-Shot）⭐ 重点

**核心原理**：在 Prompt 里塞几个示例，相当于建了一个微型数据集，让模型跟你的判断标准对齐。不动模型参数，比微调快得多。

**什么时候必须用 Few-Shot**：
- 分类任务中"标准"因业务而异（如某行业 NPS 偏低，"还行"算中性而非负面）
- 输出格式有严格要求（如法律文书特定格式）
- 模型对"好坏"的判断跟你的团队不一致

**操作步骤**：
1. 收集 3-5 个真实案例（覆盖正面、负面、边界情况）
2. 为每个案例标注期望输出
3. 按"输入→输出"格式排列在 Prompt 中
4. 把最接近目标任务的示例放在最后（近因效应）
5. 定期更新示例库（用户反馈中提取新样本）

**三档样本 + 评判标准**：

场景：产品评论情感分类（正面/负面/中性）

**好的 Few-Shot**（5个示例，覆盖边界，标注清晰）：
```
将用户评论分类为正面、负面或中性。以下是分类标准示例：

"这完全超出了我的期望，每个功能都很完美。" → 正面
（判断依据：明确的满意表达 + 具体正面细节）

"还行，但我希望它有更多功能。" → 负面
（判断依据：虽有肯定但核心诉求未被满足，整体倾向不满）

"服务尚可。既不好也不坏。" → 中性
（判断依据：没有明确倾向，纯粹的中间状态）

"包装很精美，但产品本身有些瑕疵。" → 负面
（判断依据：正面元素为非核心要素，核心产品有问题）

"用了三个月，基本满足需求。" → 中性
（判断依据：长期使用后的平淡评价，无强烈情绪）

现在分类这条评论：
```
为什么好：
- 5个示例覆盖了正/负/中三类 + 2个边界情况（"还行但希望更多"、"包装好但产品差"）
- 每个示例附判断依据，让模型理解"为什么这么分"而不是死记标签
- 边界情况（混合评价）是分类任务最容易出错的地方，专门覆盖了

**中规中矩的 Few-Shot**（3个示例，无边界覆盖）：
```
分类评论情感：
"太棒了" → 正面
"太差了" → 负面  
"一般般" → 中性

现在分类：
```
差在哪：
- 示例太极端，模型看不到混合评价怎么判断
- 没有判断依据，模型只学了表面模式
- "太棒了/太差了"这类纯粹的极端表达实际业务中很少见

**差的 Few-Shot**（示例有歧义，标注不一致）：
```
"还不错" → 正面
"还行吧" → 中性
"也还行" → 负面
```
踩了什么坑：
- 三个示例语义几乎相同但标注不同，模型会困惑
- 没有解释为什么"还不错"是正面而"也还行"是负面
- 这种不一致会让模型学到错误的模式，输出随机性极高

**Few-Shot 审美标准速查**：

| 维度 | 好 | 差 |
|------|----|----|
| 覆盖度 | 覆盖正常+边界情况 | 只有极端案例 |
| 判断依据 | 每个示例说明"为什么" | 只给标签不解释 |
| 一致性 | 相似输入→相似标签 | 相似输入→不同标签 |
| 代表性 | 示例接近真实分布 | 示例太极端/太理想 |
| 数量 | 3-5个，含至少1个边界 | 太少(10，占上下文) |

### 2.4 思维链（Chain of Thought）

**操作步骤**：
1. 在 Prompt 末尾加一句："一步一步思考，不要跳过任何步骤。"
2. 如果需要更强的控制，显式列出步骤：
   - 步骤一：确定三个最重要的发现
   - 步骤二：解释每个发现如何影响政策
   - 步骤三：写出要点摘要

**适用场景**：数学推理、逻辑分析、多步骤决策。简单任务（如翻译、格式转换）不需要。

### 2.5 提示链（Prompt Chaining）⭐ 最重要的技术

**核心原理**：把一个大 Prompt 拆成多个独立的小 Prompt，每步独立运行、独立测试。哪一步效果差，就优化哪一步。

**为什么是最重要的**：不是因为它让输出更好（有时单步也行），而是因为**它让你能定位瓶颈**。单步 Prompt 出问题，你不知道是哪个环节的错。拆开后，每步都可以独立评估和优化。

**操作步骤**：
1. **分解任务**：把一个复杂任务拆成 3-5 个独立步骤
2. **定义每步的输入/输出**：每步输入是上一步的输出
3. **独立测试每步**：用固定输入测试每步的输出质量
4. **定位瓶颈**：哪步输出最差，就优先优化哪步
5. **独立优化**：改 Prompt、换模型、加 Few-Shot，只动一步

**三档样本**：

场景：AI 帮客户写回复邮件

**好的提示链**（3步，每步职责清晰，可独立调试）：
```
提示1（提取）："从以下客户评论中提取所有关键问题和关切，以编号列表输出。"
  → 输出：1. 笔记本晚了3天 2. 包装损坏 3. 急需工作用

提示2（大纲）："基于以下客户问题，起草一个专业回复大纲。要求：承认每个关切，解释可能原因，提供具体解决方案。"
  → 输出：大纲（含三段结构）

提示3（成文）："基于以下大纲，写出完整的客户回复邮件。语气：专业但有温度。长度：150-200字。"
  → 输出：完整邮件
```
为什么好：
- 每步只做一件事，职责不交叉
- 如果邮件不好，先看大纲——大纲好说明提示3有问题；大纲差说明提示2有问题
- 可以单独给提示2加 Few-Shot 来提升大纲质量，不影响其他步骤

**中规中矩的提示链**（拆了但步骤耦合）：
```
提示1："提取客户问题并起草回复大纲。"
提示2："基于大纲写完整邮件。"
```
差在哪：提示1混合了"提取"和"起草大纲"两个任务，如果大纲不好，你不知道是提取出了问题还是大纲生成出了问题。

**差的做法**（单步塞完所有要求）：
```
"阅读这条客户评论，写一个专业回复，承认他们的关切，解释问题，提供解决方案。"
```
踩了什么坑：所有逻辑混在一起，输出不好时完全无法定位是哪个环节出了问题。改 Prompt 只能盲猜。

**提示链 vs 思维链的区别**：
- 思维链：一个 Prompt 里让模型分步思考（"一步步想"）
- 提示链：多个独立的 Prompt，每步独立执行，每步的输出是下一步的输入
- 提示链更强大，因为每步可以用不同模型、不同温度、不同 Few-Shot

### 2.6 Prompt 测试方法

三种方法按成本从低到高：

**方法1：手动 A/B 测试**
- 操作：人工对比不同版本 Prompt 的输出
- 适用：初期，案例少（2000 token）：细节丢失，跟不分块差不多
- 太小（50%的请求），允许它们直连
5. Agent 之间的通信协议 = MCP（把一个 Agent 当工具来调用）

### 7.3 智能家居案例（课堂完整案例）

| Agent | 职责 | 工具/资源 |
|-------|------|----------|
| 运动追踪 | 知道用户在家的哪个位置 | 传感器数据 |
| 温控 | 调节每个房间的温度 | HVAC API |
| 能源管理 | 追踪能耗效率 | 电表数据 |
| 安全 | 管门禁，不同成员不同权限 | 门禁系统 API |
| 环境 | 接天气API，控制百叶窗 | 天气 API |
| 食材 | 监控冰箱存货，自动下单 | 冰箱摄像头 + 电商 API |
| 编排 | 用户入口，调度所有其他 Agent | 所有其他 Agent |

组织模式：层级式为主（用户只跟编排 Agent 说话），温控和能源直连（混合式）。

---

## 模块8：未来趋势（指导技术选型）

| 趋势 | 含义 | 对我们的启示 |
|------|------|-------------|
| 性能天花板会到来 | 缩放定律终有极限，突破靠架构搜索 | 不要赌某个模型永远领先，工程手段（纵轴）才是护城河 |
| 多模态交叉增益 | 懂图片后文字也变好，模态互相增强 | 多模态数据值得投入，收益会跨模态传递 |
| 多种学习方法融合 | 预训练+监督+强化+无监督协同 | 系统设计要留接口给不同学习方式 |
| 技能半衰期极短 | 今天的最优 RAG 方法两年后可能过时 | 先有宽基础再按需深挖，不要过度投资某个具体方法 |

**操作原则**：
- 架构设计要松耦合——方便随时替换某一层的技术
- 不要在某个具体框架上 all-in——框架会过时，思维方式不会
- 投资 Eval 体系——模型和方法会变，评估能力是永久资产

---

## 8 条核心 Takeaways（按优先级）

1. **Prompt 工程是第一道防线**——投入小、产出大，先把这个做好
2. **提示链 > 单步 Prompt**——关键在于可调试性，不是输出质量
3. **尽量别做微调**——除非有极强领域需求，否则下一代模型直接超过你
4. **RAG 是知识增强的标配**——但要选对分块策略和检索方法（HyDE）
5. **构建 Agent 的第一步是任务分解**——先跟真人坐一天
6. **Eval 不是事后补课**——是系统设计的一部分，从第一天就要有
7. **多 Agent 的核心价值是并行和复用**——不是为了酷
8. **确定性和模糊性分开处理**——先把确定性的搞定，再给模糊的加护栏

---

## 概念速查表

| 概念 | 一句人话 |
|------|---------|
| 锯齿前沿（Jagged Frontier） | AI有些任务帮倒忙，你得识别边界 |
| 半人马 vs 赛博格 | 委派式（给AI一大块任务）vs 交织式（跟AI快速来回） |
| 少样本学习（Few-Shot） | 在Prompt里给几个例子，相当于建了个微型数据集 |
| 提示链（Chaining） | 把一个大Prompt拆成多步，每步独立优化 |
| HyDE | 先让AI编个假答案去搜索，比直接用问题搜更准 |
| LLM评委 | 用另一个AI来评估输出质量 |
| MCP | AI和外部服务之间的标准通信协议 |
| LLM Traces | AI系统的追踪记录，没它就没法调试 |
| 分块（Chunking） | 大文档切成小段分别存向量，检索更精确 |
| 工作记忆 vs 归档记忆 | 每次必读的（秒级）vs 偶尔才用的（可以慢） |

---

## 与曲率现有体系的完整对应

| 本课观点 | 曲率体系 | 对应关系 |
|---------|---------|---------|
| 工程增强 > 换模型 | Harness 工程 | 完全一致：同模型换 Harness 提升显著 |
| Agent 四组件 | SIP 数字员工系统 | SIP 的 Observe-Think-Act 是更细化的框架 |
| 记忆分层 | GEP 进化引擎 | 工作记忆=保留模式，归档记忆=丢弃实例 |
| Eval 四维度 | 三层评估体系 | 互补：斯坦福偏方法论，我们偏工程实现 |
| 多 Agent 层级式 | 三省六部制 | 三省六部=层级式编排，阿良=编排者 |
| 提示链可调试 | Skill 渐进式设计 | 渐进式信息披露=提示链思想 |
| 微调少碰 | Agentic Thinking | 环境设计（Harness）> 调模型参数 |
| MCP 标准协议 | MCP 集成实践 | 已有多个 MCP Server 在用 |
| 先确定性后模糊性 | Harness + Hook | 确定性=Hook物理拦截，模糊性=LLM+护栏 |

---

## 执行检查清单

设计任何 AI 系统时，按此顺序检查：

- [ ] 确认要解决的 LLM 短板（模块1的6个短板表）
- [ ] 先用 Prompt 工程能解决多少（模块2的技术栈从简到繁）
- [ ] 需要外部知识？设计 RAG（模块4，考虑 HyDE）
- [ ] 需要多步骤自主执行？设计 Agent 工作流（模块5）
- [ ] 需要并行/复用？考虑多 Agent（模块7）
- [ ] 从第一天就设计 Eval（模块6的四维度矩阵）
- [ ] 确定性和模糊性分开，模糊的加护栏
- [ ] 架构松耦合，方便未来替换任一层

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [daknniel0881-png](https://github.com/daknniel0881-png)
- **Source:** [daknniel0881-png/agent-design-skill](https://github.com/daknniel0881-png/agent-design-skill)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-daknniel0881-png-agent-design-skill-agent-design-skill
- Seller: https://agentstack.voostack.com/s/daknniel0881-png
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.
