Agent Design

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%的请求），允许它们直连

1. 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
• Source: daknniel0881-png/agent-design-skill
• License: MIT

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