Agent、Harness、Loop 核心理解
Agent、Harness、Loop 核心理解
——AI行业三大核心概念的全面深入解析
一句话理解：Agent是"能自主行动的AI"，Harness是"Agent的工具箱和操作系统"，Loop是"Agent思考和行动的循环机制"。三者合在一起，构成了现代AI应用的核心架构。
适用读者：零基础，无AI开发背景要求。本文从最基础的概念讲起，逐步构建完整的知识体系。
目录
-
第一篇：全景篇——为什么这三个概念如此重要
- 第1章 AI概念的演进脉络
- 第2章 Agent、Harness、Loop一句话定义
- 第3章 三者的关系：一个类比搞懂
-
第二篇：Agent篇——能自主行动的AI
- 第4章 什么是Agent
- 第5章 Agent的核心能力
- 第6章 Agent的类型与分类
- 第7章 Agent vs 传统AI应用
-
第三篇：Harness篇——Agent的工具箱与操作系统
- 第8章 什么是Harness
- 第9章 Harness的核心组件
- 第10章 Harness的关键机制
- 第11章 Harness的工程实践
-
第四篇：Loop篇——Agent思考和行动的循环
- 第12章 什么是Agent Loop
- 第13章 Loop的详细流程
- 第14章 Loop中的关键设计
- 第15章 Loop的高级模式
-
第五篇：融合篇——Agent+Harness+Loop的完整架构
- 第16章 完整架构详解
- 第17章 经典框架对比
- 第18章 实战案例
-
第六篇：前沿与展望
- 第19章 当前挑战
- 第20章 未来趋势
- 附录
第一篇：全景篇——为什么这三个概念如此重要
第1章 AI概念的演进脉络
1.1 从ChatGPT到Agent的演进
2022年底：ChatGPT发布
→ 人们发现AI可以对话了
→ 但只能问答，不能做事
2023年：提示词工程（Prompt Engineering）
→ 人们发现"怎么问"比"问什么"更重要
→ 通过精心设计提示词来引导AI输出更好的结果
→ 局限：仍然是一问一答，不能自主行动
2024年：Agent概念爆发
→ 人们发现AI可以"自己做事"了
→ 不只是回答问题，而是自主规划、执行、反思
→ 关键突破：AI从"被动回答"变成"主动执行"
2025年：Harness Engineering + Agent Loop
→ 人们发现光有Agent不够，还需要"操作系统"和"工作流程"
→ Harness：给Agent提供工具、上下文、约束
→ Loop：定义Agent如何思考-行动-观察的循环
→ 三者合一，构成完整的AI应用架构
1.2 概念关系图
┌─────────────────────────────────────────────────────────┐
│ AI应用的完整架构 │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Agent（智能体） │ │
│ │ · 能理解任务 │ │
│ │ · 能自主规划 │ │
│ │ · 能调用工具 │ │
│ │ · 能反思改进 │ │
│ └──────────────────────┬───────────────────────────┘ │
│ │ │
│ │ 运行在 │
│ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Harness（工具箱） │ │
│ │ · 工具注册（搜索、代码执行、API调用...） │ │
│ │ · 上下文管理（记忆、历史、文件...） │ │
│ │ · 权限控制（安全边界、沙箱...） │ │
│ │ · 环境交互（文件系统、终端、浏览器...） │ │
│ └──────────────────────┬───────────────────────────┘ │
│ │ │
│ │ 通过 │
│ ▼ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ Agent Loop（执行循环） │ │
│ │ · 思考（Think）→ 规划下一步 │ │
│ │ · 行动（Act）→ 调用工具执行 │ │
│ │ · 观察（Observe）→ 获取结果 │ │
│ │ · 判断（Judge）→ 是否完成/需要继续 │ │
│ └──────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
1.3 相关概念速查
| 概念 | 英文 | 一句话解释 | 与Agent的关系 |
|---|---|---|---|
| Agent | Agent | 能自主行动的AI | 核心主体 |
| Harness | Harness | Agent的工具箱和运行环境 | Agent的基础设施 |
| Loop | Agent Loop | Agent思考-行动-观察的循环 | Agent的执行机制 |
| Tool | Tool | Agent可以调用的具体功能 | Harness中的组件 |
| Skill | Skill | 预定义的任务能力模块 | Agent的可复用能力 |
| Context | Context | Agent可用的上下文信息 | Harness管理的内容 |
| Prompt | Prompt | 给AI的指令/提示 | Agent的输入 |
| Orchestration | Orchestration | 多Agent的协调编排 | Agent的协作机制 |
| Grounding | Grounding | 让AI输出基于事实 | Agent的可靠性保障 |
第2章 Agent、Harness、Loop一句话定义
2.1 Agent（智能体）
Agent = 一个能自主理解任务、规划步骤、调用工具、执行行动、反思改进的AI系统
关键词：自主、规划、工具、执行、反思
与传统AI的区别：
传统AI：你问一句，它答一句（被动）
Agent：你给一个目标，它自己想办法完成（主动）
2.2 Harness（工具箱/运行环境）
Harness = 为Agent提供工具、上下文、权限、环境的基础设施层
关键词：工具注册、上下文管理、权限控制、环境交互
类比：
如果Agent是一个工人，Harness就是他的工具间+工作台+操作手册
2.3 Loop（执行循环）
Agent Loop = Agent执行任务时"思考→行动→观察→判断"的循环过程
关键词：思考(Think)、行动(Act)、观察(Observe)、判断(Judge)
类比：
如果Agent是一个厨师，Loop就是他做菜的流程：
看菜谱(Think) → 切菜炒菜(Act) → 尝味道(Observe) → 判断是否做好(Judge)
→ 没好就继续调整 → 好了就上菜
第3章 三者的关系：一个类比搞懂
3.1 外科手术的类比
想象一个外科手术室：
Agent = 外科医生
· 有专业知识（医学知识 = AI的预训练知识）
· 能理解手术目标（"切除肿瘤" = 用户指令）
· 能规划手术步骤（先切开、再分离、再切除...）
· 能执行具体操作（用手术刀切、用钳子夹...）
Harness = 手术室 + 器械护士
· 提供手术器械（手术刀、钳子、缝合针 = 工具Tools）
· 提供患者信息（病历、影像、化验结果 = 上下文Context）
· 控制手术环境（无菌环境、监护仪、麻醉 = 权限/环境控制）
· 传递器械（护士把器械递给医生 = 工具调用机制）
Loop = 手术流程
· 评估患者状态（Think）
· 执行手术操作（Act）
· 观察手术效果（Observe）
· 判断是否继续（Judge：出血量、肿瘤是否切净...）
· 循环直到手术完成
3.2 编程世界的类比
Agent = 程序员
Harness = IDE（集成开发环境）+ 终端 + 文件系统 + API
Loop = 编程工作流（写代码→运行→看结果→修改→再运行）
具体来说：
一个AI编程Agent的工作方式：
用户："帮我写一个贪吃蛇游戏"
Agent Loop第1轮：
Think：需要创建HTML+CSS+JavaScript文件
Act：调用write_file工具，写入index.html
Observe：文件创建成功
Judge：主文件创建完成，还需要JS逻辑
Agent Loop第2轮：
Think：需要写游戏逻辑
Act：调用write_file工具，写入game.js
Observe：文件创建成功
Judge：代码写完了，需要测试
Agent Loop第3轮：
Think：打开浏览器测试
Act：调用browser工具，打开index.html
Observe：游戏界面出现了，但蛇不能移动
Judge：有bug，需要修复键盘事件
Agent Loop第4轮：
Think：键盘事件监听代码有误
Act：调用edit_file工具，修复代码
Observe：重新加载，蛇可以移动了
Judge：游戏功能正常，任务完成
3.3 三者的本质关系
Agent是"谁"——主体、角色、智能体
Harness是"用什么"——工具、环境、资源
Loop是"怎么做"——流程、循环、工作机制
三者缺一不可：
· 没有Agent：只有工具和流程，但没有智能来决策和规划
· 没有Harness：Agent有智能但没有工具可用，"巧妇难为无米之炊"
· 没有Loop：Agent有工具但不知道如何系统地工作，可能一步做完就停了
第二篇：Agent篇——能自主行动的AI
第4章 什么是Agent
4.1 Agent的正式定义
AI Agent（人工智能智能体）= 一个能够感知环境、自主决策、采取行动以达成目标的AI系统。
核心特征：
1. 自主性（Autonomy）：不需要人类逐步指导，能自己决定下一步做什么
2. 目标导向（Goal-oriented）：有明确的任务目标，并为之努力
3. 环境感知（Perception）：能感知外部环境的状态（通过工具获取信息）
4. 行动能力（Action）：能采取行动改变环境（通过工具执行操作）
5. 适应性（Adaptability）：能根据反馈调整策略
4.2 Agent vs 普通AI应用
| 维度 | 普通AI应用（如ChatGPT） | Agent |
|---|---|---|
| 交互模式 | 一问一答 | 自主执行多步任务 |
| 工具使用 | 无或有限 | 可调用多种外部工具 |
| 规划能力 | 无（每次独立响应） | 有（能制定多步计划） |
| 记忆 | 仅限对话上下文 | 可有长期记忆 |
| 执行能力 | 只输出文本 | 可执行代码、操作文件、调用API |
| 反思能力 | 无 | 能从错误中学习和调整 |
| 典型任务 | “写一首诗” | “帮我搭建一个网站，包含首页、关于页面和联系方式” |
4.3 Agent的核心组成
一个完整的Agent包含：
┌─────────────────────────────────────────┐
│ Agent │
│ │
│ ┌─────────────┐ ┌─────────────────┐ │
│ │ 大脑 │ │ 感知系统 │ │
│ │ (LLM) │ │ (输入处理) │ │
│ │ · 理解任务 │ │ · 文本输入 │ │
│ │ · 推理规划 │ │ · 图像输入 │ │
│ │ · 决策判断 │ │ · 文件输入 │ │
│ └──────┬──────┘ └────────┬────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────────────────────┐ │
│ │ 规划与决策模块 │ │
│ │ · 任务分解 │ │
│ │ · 策略选择 │ │
│ │ · 工具选择 │ │
│ └──────────────┬──────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────┐ │
│ │ 行动执行模块 │ │
│ │ · 调用工具（Tools） │ │
│ │ · 生成代码 │ │
│ │ · 操作环境 │ │
│ └──────────────┬──────────────────┘ │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────┐ │
│ │ 记忆与反思模块 │ │
│ │ · 短期记忆（当前对话） │ │
│ │ · 长期记忆（历史经验） │ │
│ │ · 反思与学习 │ │
│ └─────────────────────────────────┘ │
│ │
└─────────────────────────────────────────┘
第5章 Agent的核心能力
5.1 能力一：理解与推理
Agent需要理解用户的意图，并进行推理：
用户："我的网站加载很慢，帮我优化一下"
Agent的推理过程：
1. 理解意图：用户想优化网站性能
2. 分析可能原因：
- 图片未压缩
- CSS/JS未合并
- 没有使用CDN
- 数据库查询慢
- ...
3. 制定计划：
- 先分析当前性能（用Lighthouse工具）
- 根据结果逐一优化
- 验证优化效果
5.2 能力二：规划与分解
Agent能将复杂任务分解为可执行的子任务：
任务："帮我创建一个Python爬虫，抓取某网站的商品信息并保存为CSV"
Agent的规划：
Step 1: 分析目标网站的结构
Step 2: 安装必要的库（requests, beautifulsoup4）
Step 3: 编写爬虫代码
Step 4: 测试爬虫
Step 5: 处理异常和反爬机制
Step 6: 运行爬虫并保存数据
Step 7: 验证CSV文件内容
5.3 能力三：工具调用
Agent能调用外部工具来完成任务：
可用工具示例：
· 代码执行器：运行Python/JavaScript代码
· 文件操作：读写文件、创建目录
· 终端命令：执行shell命令
· 网络搜索：搜索互联网信息
· API调用：调用第三方服务
· 浏览器：打开网页、截图
· 数据库：查询和修改数据
工具调用的格式（通常）：
{
"tool": "run_code",
"arguments": {
"language": "python",
"code": "print('Hello World')"
}
}
5.4 能力四：反思与改进
Agent能从错误中学习和调整：
第1次尝试：运行代码 → 报错：ModuleNotFoundError
反思：缺少依赖包
第2次尝试：安装依赖 → 再次运行 → 报错：IndexError
反思：列表索引越界，需要检查数据长度
第3次尝试：添加边界检查 → 运行成功
判断：任务完成
5.5 能力五：上下文管理
Agent需要管理多轮交互的上下文：
上下文包括：
· 用户的原始请求
· Agent的执行历史（做了什么、结果如何）
· 中间状态（变量、文件、数据）
· 约束和偏好（用户的限制条件）
· 长期记忆（之前任务的经验）
第6章 Agent的类型与分类
6.1 按自主程度分类
Level 0：无Agent（传统AI）
→ 一问一答，没有自主性
→ 例子：原始ChatGPT
Level 1：简单Agent
→ 能调用工具，但每步都需要用户确认
→ 例子：ChatGPT + Code Interpreter
Level 2：自主Agent
→ 能自主规划和执行，但可能出错
→ 例子：Devin, Cursor Agent
Level 3：协作Agent
→ 多个Agent协作完成复杂任务
→ 例子：AutoGen, CrewAI
Level 4：完全自主Agent
→ 能独立完成复杂项目，几乎不需要人类干预
→ 目前尚在探索中
6.2 按应用领域分类
| 类型 | 应用场景 | 代表产品 |
|---|---|---|
| 编程Agent | 写代码、调试、部署 | Cursor, Devin, GitHub Copilot |
| 研究Agent | 搜索信息、分析数据、撰写报告 | Perplexity, GPT Researcher |
| 操作Agent | 操作电脑、浏览器、手机 | Claude Computer Use, Project Mariner |
| 数据Agent | 数据分析、可视化、报告生成 | Julius, ChatGPT Data Analysis |
| 客服Agent | 自动回复客户问题 | 各类客服机器人 |
| 工作流Agent | 自动化业务流程 | Zapier AI, Make AI |
6.3 按架构模式分类
单Agent模式：
一个Agent独立完成所有工作
优点：简单、可控
缺点：能力有限、上下文容易溢出
多Agent模式：
多个专业Agent协作完成任务
例子：
· 规划Agent：负责任务分解
· 编码Agent：负责写代码
· 测试Agent：负责测试验证
· 审查Agent：负责代码审查
层级模式：
一个主Agent管理多个子Agent
主Agent负责分配任务和协调
子Agent负责具体执行
第7章 Agent vs 传统AI应用
7.1 具体对比
场景：用户说"帮我分析这份销售数据，找出最畅销的产品，并生成报告"
传统AI应用（如ChatGPT直接对话）：
用户上传文件 → AI读取数据 → AI在回复中给出分析文本
局限：
· 不能自动运行代码来分析数据
· 不能生成可视化图表文件
· 不能自动保存报告文件
· 需要用户手动复制代码并运行
Agent：
1. 接收文件 → 调用read_file工具读取数据
2. 分析数据 → 调用run_code工具执行Python分析代码
3. 生成图表 → 调用run_code工具生成可视化图表
4. 生成报告 → 调用write_file工具写入报告文件
5. 返回结果 → 告诉用户报告已生成，附上文件路径
优势：
· 全自动完成，不需要用户手动操作
· 能执行代码、操作文件、生成实际产出物
· 如果中间出错，能自动调试和重试
7.2 为什么Agent是AI的未来
Agent解决了AI的"最后一公里"问题：
传统AI：能说不能做
→ 告诉你怎么做，但不能帮你做
Agent：能说也能做
→ 不仅告诉你怎么做，还帮你做了
这就像：
传统AI = 一个百科全书（知道所有知识，但不能行动）
Agent = 一个全能助手（知道所有知识，还能帮你做事）
第三篇：Harness篇——Agent的工具箱与操作系统
第8章 什么是Harness
8.1 Harness的定义
Harness = 为Agent提供运行环境、工具、上下文和约束的基础设施层
"Harness"这个词的原意是"马具/挽具"——套在马身上，让骑手能够控制马匹。
在AI领域，Harness就是"套在LLM身上"的基础设施，让开发者能够控制和增强Agent的能力。
8.2 为什么需要Harness
裸的LLM（如GPT-4 API）只能：
· 接收文本输入
· 输出文本回复
· 不能访问文件系统
· 不能执行代码
· 不能调用API
· 不能上网搜索
Harness赋予LLM"超能力"：
· 工具调用（Tools）：让LLM能执行代码、操作文件、调用API
· 上下文管理（Context）：让LLM能记住历史、访问文件、获取实时信息
· 权限控制（Permissions）：限制LLM能做什么、不能做什么
· 环境交互（Environment）：让LLM能与外部世界交互
8.3 Harness在整体架构中的位置
┌──────────────────────────────────────────┐
│ 用户 │
│ （输入任务/指令） │
└────────────────┬─────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Agent（LLM） │
│ （理解任务、规划、决策） │
└────────────────┬─────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ Harness（基础设施） │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 工具管理 │ │ 上下文管理│ │ 权限控制 │ │
│ │ │ │ │ │ │ │
│ │ · 代码执行│ │ · 对话历史│ │ · 沙箱 │ │
│ │ · 文件操作│ │ · 文件内容│ │ · 权限 │ │
│ │ · 搜索 │ │ · 系统提示│ │ · 审计 │ │
│ │ · API调用│ │ · 长期记忆│ │ · 限流 │ │
│ └──────────┘ └──────────┘ └──────────┘ │
│ │
└────────────────┬─────────────────────────┘
│
▼
┌──────────────────────────────────────────┐
│ 外部环境 │
│ · 文件系统 · 终端 · 浏览器 · API · 数据库│
└──────────────────────────────────────────┘
第9章 Harness的核心组件
9.1 组件一：工具管理（Tool Management）
工具管理是Harness最核心的功能——注册、发现、调用工具。
工具注册示例：
{
"name": "run_python",
"description": "执行Python代码并返回结果",
"parameters": {
"code": {
"type": "string",
"description": "要执行的Python代码"
}
},
"returns": {
"type": "string",
"description": "代码执行的输出结果"
}
}
常见工具类型：
· 代码执行：run_python, run_javascript, run_shell
· 文件操作：read_file, write_file, edit_file, list_files
· 网络访问：web_search, fetch_url, browse_web
· 数据操作：query_database, parse_csv, analyze_data
· 通信工具：send_email, send_message, make_api_call
· 系统操作：run_command, check_status, manage_process
9.2 组件二：上下文管理（Context Management）
上下文管理负责维护Agent工作时需要的所有信息。
上下文的组成：
┌─────────────────────────────────────┐
│ 上下文（Context） │
│ │
│ ┌─────────────────────────────┐ │
│ │ 系统提示（System Prompt） │ │
│ │ · Agent的角色定义 │ │
│ │ · 可用工具列表 │ │
│ │ · 行为约束和规则 │ │
│ └─────────────────────────────┘ │
│ │
│ ┌─────────────────────────────┐ │
│ │ 对话历史（Conversation） │ │
│ │ · 用户的请求 │ │
│ │ · Agent的回复 │ │
│ │ · 工具调用和结果 │ │
│ └─────────────────────────────┘ │
│ │
│ ┌─────────────────────────────┐ │
│ │ 工作文件（Working Files） │ │
│ │ · 当前正在编辑的文件 │ │
│ │ · 生成的中间结果 │ │
│ └─────────────────────────────┘ │
│ │
│ ┌─────────────────────────────┐ │
│ │ 长期记忆（Long-term Memory） │ │
│ │ · 用户偏好 │ │
│ │ · 项目知识 │ │
│ │ · 历史经验 │ │
│ └─────────────────────────────┘ │
│ │
└─────────────────────────────────────┘
9.3 组件三：权限控制（Permission Control）
权限控制确保Agent在安全边界内工作。
权限维度：
· 工具权限：哪些工具可以使用，哪些禁止
· 文件权限：可以读写哪些目录，哪些文件只读
· 网络权限：可以访问哪些URL，是否允许外网
· 执行权限：可以执行哪些命令，是否需要确认
· 资源限制：最大执行时间、内存限制、Token限制
安全机制：
· 沙箱（Sandbox）：在隔离环境中执行代码
· 确认机制（Confirmation）：危险操作前需要用户确认
· 审计日志（Audit Log）：记录所有操作以便追溯
· 限流（Rate Limiting）：防止Agent过度消耗资源
9.4 组件四：环境交互（Environment Interaction）
环境交互让Agent能与外部世界交互。
交互方式：
· 文件系统：读写本地文件
· 终端/Shell：执行命令行命令
· 浏览器：打开网页、截图、填表
· API：调用第三方服务（GitHub, Slack, 数据库等）
· 操作系统：窗口管理、键盘鼠标操作
环境抽象层：
Agent不需要知道底层实现细节
通过统一的工具接口与环境交互
不同环境（本地/云端/容器）提供相同的工具接口
第10章 Harness的关键机制
10.1 工具描述（Tool Description）
好的工具描述是Agent正确使用工具的关键。
差的工具描述：
{
"name": "search",
"description": "搜索"
}
→ Agent不知道搜什么、怎么搜、返回什么
好的工具描述：
{
"name": "web_search",
"description": "在互联网上搜索信息。输入搜索关键词，返回搜索结果列表。每个结果包含标题、URL和摘要。适用于需要查找最新信息、验证事实、获取参考资料的场景。",
"parameters": {
"query": {
"type": "string",
"description": "搜索关键词，建议使用简洁明确的关键词",
"required": true
},
"num_results": {
"type": "integer",
"description": "返回结果数量，默认5，最大10",
"required": false,
"default": 5
}
}
}
→ Agent清楚地知道这个工具能做什么、怎么用、返回什么
10.2 上下文窗口管理
LLM有上下文窗口限制（如128K token），Harness需要管理上下文不超限。
管理策略：
1. 滑动窗口：保留最近的N轮对话，丢弃早期的
2. 摘要压缩：将早期对话压缩为摘要
3. 重要性排序：保留重要的上下文，丢弃不重要的
4. 外部存储：将不常用的上下文存储到外部（如数据库），按需加载
示例：
原始对话历史：50轮，约100K token
→ 滑动窗口保留最近10轮：约20K token
→ 早期40轮压缩为摘要：约2K token
→ 总上下文：约22K token（在限制内）
10.3 系统提示设计
系统提示（System Prompt）定义了Agent的角色、能力和行为规范。
示例系统提示：
┌──────────────────────────────────────────────────┐
│ 你是一个专业的软件开发助手。 │
│ │
│ 能力： │
│ · 你可以读写文件、执行代码、搜索信息 │
│ · 你可以分析需求、设计方案、编写代码 │
│ · 你可以调试程序、运行测试、部署应用 │
│ │
│ 规则： │
│ · 在修改文件前，先读取当前内容 │
│ · 在执行可能有副作用的操作前，先向用户确认 │
│ · 如果遇到错误，先分析原因再尝试修复 │
│ · 代码要写注释，保持良好的代码风格 │
│ · 完成任务后，总结做了什么 │
│ │
│ 可用工具： │
│ [工具列表会在运行时动态注入] │
└──────────────────────────────────────────────────┘
第11章 Harness的工程实践
11.1 模块化设计
好的Harness应该是模块化的，各组件可插拔：
┌─────────────────────────────────────┐
│ Harness 框架 │
│ │
│ ┌─────────────────────────────┐ │
│ │ Tool Registry │ │
│ │ · 注册工具 │ │
│ │ · 发现工具 │ │
│ │ · 调用工具 │ │
│ └─────────────────────────────┘ │
│ │
│ ┌─────────────────────────────┐ │
│ │ Context Manager │ │
│ │ · 管理对话历史 │ │
│ │ · 管理文件上下文 │ │
│ │ · 管理长期记忆 │ │
│ └─────────────────────────────┘ │
│ │
│ ┌─────────────────────────────┐ │
│ │ Permission Manager │ │
│ │ · 权限检查 │ │
│ │ · 沙箱管理 │ │
│ │ · 审计日志 │ │
│ └─────────────────────────────┘ │
│ │
│ ┌─────────────────────────────┐ │
│ │ Environment Adapter │ │
│ │ · 文件系统适配 │ │
│ │ · 终端适配 │ │
│ │ · 浏览器适配 │ │
│ │ · API适配 │ │
│ └─────────────────────────────┘ │
│ │
└─────────────────────────────────────┘
11.2 Harness Engineering（工具箱工程）
Harness Engineering = 设计和构建Agent运行环境的工程实践
核心工作：
1. 工具设计：定义Agent可以使用哪些工具，每个工具的接口是什么
2. 上下文设计：决定哪些信息应该放入Agent的上下文
3. 权限设计：确定Agent的安全边界
4. 提示设计：设计系统提示，引导Agent的行为
5. 错误处理：设计工具调用失败时的处理策略
6. 性能优化：减少不必要的工具调用，优化上下文大小
关键原则：
· 工具描述要清晰：Agent通过描述来理解工具的用途
· 工具数量要适中：太少限制能力，太多增加选择难度
· 上下文要精简：只放必要信息，避免噪声干扰
· 权限要最小化：只给Agent完成任务所需的最小权限
· 错误要友好：工具失败时返回清晰的错误信息
第四篇：Loop篇——Agent思考和行动的循环
第12章 什么是Agent Loop
12.1 Agent Loop的定义
Agent Loop = Agent执行任务时不断重复的"思考→行动→观察→判断"循环
核心思想：
Agent不是一次性完成任务的
而是通过多轮循环，逐步逼近目标
每一轮循环，Agent都会：
1. 思考当前状态和下一步计划
2. 采取一个具体行动
3. 观察行动的结果
4. 判断是否完成目标
5. 如果没有完成，回到第1步继续
12.2 为什么需要Loop
为什么Agent不能一次性完成所有事情？
1. 信息不完整：Agent一开始不知道所有信息，需要通过行动获取
例如：不知道文件内容，需要先读取才能编辑
2. 任务复杂：复杂任务需要多步完成
例如：创建网站需要创建多个文件、安装依赖、测试运行
3. 需要验证：行动的结果需要检验
例如：写了代码需要运行看看是否正确
4. 可能出错：第一次尝试可能失败，需要调整策略
例如：代码有bug需要调试修复
Loop让Agent能够：
· 渐进式地完成任务
· 从错误中恢复
· 根据中间结果调整策略
· 在每一步都做出最优决策
12.3 Agent Loop的生命周期
一个完整的Agent Loop生命周期：
开始
│
▼
┌──────────────┐
│ 接收用户任务 │
└──────┬───────┘
│
▼
┌──────────────┐
│ 理解任务意图 │ ← LLM分析用户需求
└──────┬───────┘
│
▼
┌──────────────┐
│ 制定执行计划 │ ← LLM规划步骤
└──────┬───────┘
│
▼
┌──────────────────────────────────────┐
│ Agent Loop 循环 │
│ │
│ ┌─────────┐ │
│ │ Think │ ← 思考当前状态和下一步 │
│ └────┬────┘ │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │ Act │ ← 调用工具执行行动 │
│ └────┬────┘ │
│ │ │
│ ▼ │
│ ┌─────────┐ │
│ │ Observe │ ← 获取行动结果 │
│ └────┬────┘ │
│ │ │
│ ▼ │
│ ┌─────────┐ 是 │
│ │ Judge │ ─────────→ 任务完成 │
│ │ 完成？ │ │
│ └────┬────┘ │
│ │否 │
│ └────→ 回到 Think ────────────┘│
│ │
└──────────────────────────────────────┘
│
▼
┌──────────────┐
│ 返回结果给用户 │
└──────────────┘
第13章 Loop的详细流程
13.1 Think（思考）
Think阶段：Agent分析当前状态，决定下一步做什么。
Agent的思考过程（由LLM完成）：
· 回顾：我做了什么？结果如何？
· 分析：当前状态是什么？有什么问题？
· 规划：下一步应该做什么？用什么工具？
· 决策：选择最优的行动方案
思考的输出：
· 内部推理文本（Chain of Thought）
· 选择的工具和参数
示例：
当前状态：用户要求创建一个网页，我已经创建了HTML文件
分析：HTML文件已创建，但还没有CSS样式
规划：下一步创建CSS文件来美化页面
决策：调用write_file工具，写入style.css
13.2 Act（行动）
Act阶段：Agent执行具体的行动，通常是调用一个工具。
行动的格式：
{
"thought": "需要创建CSS文件来美化页面",
"action": "write_file",
"action_input": {
"path": "style.css",
"content": "body { font-family: Arial; margin: 0; padding: 20px; }"
}
}
行动的特点：
· 每次行动通常只调用一个工具（原子操作）
· 行动的参数由Think阶段的决策决定
· 行动会产一个具体的结果
13.3 Observe（观察）
Observe阶段：Agent获取行动的结果。
观察的内容：
· 工具调用的返回值
· 执行是否成功
· 任何错误信息
· 环境的变化
示例：
工具调用：write_file("style.css", "body { ... }")
观察结果：
{
"status": "success",
"message": "文件 style.css 已创建",
"path": "/project/style.css"
}
或者失败情况：
{
"status": "error",
"message": "权限不足，无法写入 /protected/style.css"
}
13.4 Judge（判断）
Judge阶段：Agent评估当前状态，决定是继续还是结束。
判断依据：
· 原始任务是否已完成？
· 是否遇到了无法解决的问题？
· 是否需要用户输入更多信息？
· 是否达到了最大循环次数？
判断结果：
· 继续（Continue）：回到Think阶段继续
· 完成（Done）：任务已完成，返回结果
· 失败（Failed）：无法完成任务，返回错误说明
· 需要输入（Need Input）：需要用户提供更多信息
示例：
任务："创建一个包含首页和关于页面的网站"
已完成：创建了index.html和style.css
未完成：还没有创建about.html
判断：继续 → 回到Think阶段创建about.html
第14章 Loop中的关键设计
14.1 循环终止条件
必须设置终止条件，防止Agent无限循环：
终止条件：
1. 任务完成：Agent判断任务已完成
2. 最大循环次数：如最多50轮循环
3. 最大Token消耗：如最多消耗100K token
4. 最大时间：如最多运行10分钟
5. 连续失败：如连续3次行动失败
6. 用户中断：用户手动停止
示例代码：
max_iterations = 50
iteration = 0
while iteration < max_iterations:
thought = agent.think(context)
action = agent.decide_action(thought)
result = execute_tool(action)
observation = agent.observe(result)
if agent.judge_complete(observation):
return agent.get_final_result()
context.update(thought, action, result, observation)
iteration += 1
return "任务未能在限定循环次数内完成"
14.2 错误处理与重试
Loop中的错误处理策略：
策略一：直接重试
工具调用失败 → 稍微修改参数 → 重新调用
适用于：临时性错误（如网络超时）
策略二：换一种方法
方法A失败 → Think阶段分析原因 → 选择方法B
适用于：方法选择错误（如用错了工具）
策略三：请求帮助
自己解决不了 → 向用户请求更多信息或指导
适用于：信息不足或权限不够
策略四：优雅降级
完美方案做不到 → 退而求其次
适用于：资源或能力限制
示例：
Loop 1: 读取文件 → 失败（文件不存在）
Think: 文件不存在，可能路径有误
Loop 2: 列出目录文件 → 成功，发现文件名不同
Think: 找到了正确的文件名
Loop 3: 读取正确文件 → 成功
14.3 上下文更新
每轮循环后，需要更新Agent的上下文：
上下文更新内容：
· 添加本轮的思考过程
· 添加本轮的工具调用和结果
· 更新当前状态
· 更新任务进度
上下文压缩（防止溢出）：
· 保留最近N轮的完整记录
· 将更早的记录压缩为摘要
· 保留关键信息（错误、重要结果）
· 丢弃冗余信息（重复的中间状态）
14.4 单步 vs 多步执行
单步执行模式：
Think → Act(工具A) → Observe → Judge
Think → Act(工具B) → Observe → Judge
Think → Act(工具C) → Observe → Judge
每轮只执行一个工具调用
优点：简单、可控
缺点：轮次多、慢
多步执行模式：
Think → Act(工具A) → Act(工具B) → Act(工具C) → Observe → Judge
一轮中连续执行多个工具调用
优点：快、效率高
缺点：错误处理复杂
实际中通常使用单步模式，因为：
· 每步的结果可能影响下一步的决策
· 单步模式更容易调试和理解
· 错误更容易定位和处理
第15章 Loop的高级模式
15.1 ReAct模式（Reasoning + Acting）
ReAct = 推理(Reasoning) + 行动(Acting)
最经典的Agent Loop模式，由论文"ReAct: Synergizing Reasoning and Acting in Language Models"提出。
核心思想：
在每一步行动前，先进行显式的推理
推理和行动交替进行
流程：
Thought: 我需要找到Python的版本
Action: run_command("python --version")
Observation: Python 3.10.12
Thought: 确认Python版本是3.10，可以使用match语句
Action: write_file("main.py", "match ...")
Observation: 文件创建成功
Thought: 代码已写好，需要测试
Action: run_command("python main.py")
Observation: 输出正确
Thought: 任务完成
Final Answer: 已创建main.py文件并测试通过
15.2 Plan-and-Execute模式
先制定完整计划，然后逐步执行。
流程：
Step 1: Plan（规划）
Agent制定完整的任务计划：
1. 创建项目目录
2. 创建HTML文件
3. 创建CSS文件
4. 创建JS文件
5. 测试运行
Step 2: Execute（执行）
按照计划逐步执行，每步一个Loop
Step 3: Re-plan（重新规划，可选）
如果某步失败或发现新信息，可能需要修改计划
优点：
· 有全局视野，不会迷失方向
· 用户可以在执行前审核计划
· 更适合复杂任务
缺点：
· 初始计划可能不准确
· 灵活性不如ReAct
15.3 Reflection模式
在行动后增加反思环节，从经验中学习。
流程：
Think → Act → Observe → Reflect → Judge
↑
反思环节
· 这步做得对吗？
· 有没有更好的方法？
· 学到了什么经验？
反思的作用：
· 避免重复犯同样的错误
· 发现更好的解决方案
· 积累任务特定的经验
示例：
Loop 1: 尝试用requests库爬取网页 → 返回403
Reflect: 网站有反爬机制，需要添加User-Agent
Loop 2: 添加User-Agent头 → 成功获取数据
Reflect: 爬虫需要模拟浏览器行为
（这个经验可用于后续爬虫任务）
15.4 Multi-Agent Loop
多个Agent协作，每个Agent有自己的Loop。
模式一：顺序协作
Agent A完成 → 结果传给Agent B → Agent B完成 → 结果传给Agent C
模式二：并行协作
Agent A和Agent B同时执行不同子任务 → 合并结果
模式三：层级协作
主Agent分解任务 → 分配给子Agent → 子Agent执行 → 汇报给主Agent
示例（代码审查场景）：
主Agent：接收代码审查请求，分配任务
编码Agent：分析代码逻辑
安全Agent：检查安全漏洞
性能Agent：分析性能问题
主Agent：汇总各Agent的发现，生成审查报告
第五篇：融合篇——Agent+Harness+Loop的完整架构
第16章 完整架构详解
16.1 完整架构图
┌─────────────────────────────────────────────────────────────┐
│ 用户界面 │
│ （Web/CLI/API/Mobile） │
└──────────────────────────┬──────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Agent（智能体） │
│ │
│ ┌─────────────────────────────────────────────────────┐ │
│ │ LLM（大语言模型） │ │
│ │ · 理解、推理、规划、决策 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ │
│ ┌──────────────────────▼──────────────────────────────┐ │
│ │ Agent Loop（执行循环） │ │
│ │ · Think → Act → Observe → Judge │ │
│ │ · 循环控制、错误处理、终止条件 │ │
│ └──────────────────────┬──────────────────────────────┘ │
│ │ │
└─────────────────────────┼───────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────┐
│ Harness（基础设施） │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Tool Registry│ │Context Manager│ │Permission Mgr │ │
│ │ │ │ │ │ │ │
│ │ · 代码执行 │ │ · 系统提示 │ │ · 沙箱 │ │
│ │ · 文件操作 │ │ · 对话历史 │ │ · 权限检查 │ │
│ │ · 网络搜索 │ │ · 文件上下文 │ │ · 审计日志 │ │
│ │ · API调用 │ │ · 长期记忆 │ │ · 限流 │ │
│ │ · 浏览器 │ │ · 压缩管理 │ │ · 确认机制 │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │
│ └────────────────┼────────────────┘ │
│ │ │
│ ┌───────────────────────▼──────────────────────────────┐ │
│ │ Environment Adapter（环境适配器） │ │
│ │ · 文件系统 · 终端 · 浏览器 · API · 数据库 │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
16.2 一次完整的Agent执行流程
用户："帮我创建一个TODO应用，支持添加、删除和标记完成功能"
═══════════════════════════════════════════════════
Agent Loop 第1轮
═══════════════════════════════════════════════════
Think:
用户要一个TODO应用，需要添加、删除、标记完成。
我应该创建一个简单的Web应用，使用HTML+CSS+JavaScript。
计划：
1. 创建index.html（主页面）
2. 创建style.css（样式）
3. 创建app.js（逻辑）
4. 测试运行
先创建HTML文件。
Act: 调用 write_file 工具
path: "todo/index.html"
content: "<!DOCTYPE html>..."
Observe: 文件创建成功
Judge: HTML文件创建完成，继续
═══════════════════════════════════════════════════
Agent Loop 第2轮
═══════════════════════════════════════════════════
Think: HTML已创建，接下来创建CSS样式文件。
Act: 调用 write_file 工具
path: "todo/style.css"
content: "body { font-family: Arial; }..."
Observe: 文件创建成功
Judge: CSS文件创建完成，继续
═══════════════════════════════════════════════════
Agent Loop 第3轮
═══════════════════════════════════════════════════
Think: CSS已创建，接下来创建JavaScript逻辑文件。
Act: 调用 write_file 工具
path: "todo/app.js"
content: "function addTodo() { ... }..."
Observe: 文件创建成功
Judge: JS文件创建完成，需要测试
═══════════════════════════════════════════════════
Agent Loop 第4轮
═══════════════════════════════════════════════════
Think: 代码已写完，打开浏览器测试。
Act: 调用 open_browser 工具
url: "todo/index.html"
Observe: 页面打开了，可以添加TODO，但删除按钮不工作
Judge: 发现bug，需要修复
═══════════════════════════════════════════════════
Agent Loop 第5轮
═══════════════════════════════════════════════════
Think: 删除按钮不工作，可能是事件绑定问题。检查app.js中的deleteTodo函数。
Act: 调用 read_file 工具
path: "todo/app.js"
Observe: 发现deleteTodo函数中的选择器写错了
Think: 找到问题，修复选择器。
Act: 调用 edit_file 工具
path: "todo/app.js"
old: "querySelector('.wrong-class')"
new: "querySelector('.delete-btn')"
Observe: 代码修改成功
Judge: 修复完成，需要重新测试
═══════════════════════════════════════════════════
Agent Loop 第6轮
═══════════════════════════════════════════════════
Think: 重新测试应用。
Act: 调用 open_browser 工具
url: "todo/index.html"
Observe: 应用正常工作，添加、删除、标记完成都正常
Judge: 任务完成！
═══════════════════════════════════════════════════
返回结果
═══════════════════════════════════════════════════
"TODO应用已创建完成，包含以下文件：
- todo/index.html（主页面）
- todo/style.css（样式文件）
- todo/app.js（逻辑文件）
功能：添加TODO、删除TODO、标记完成
中间修复了一个删除按钮的bug。"
第17章 经典框架对比
17.1 主流Agent框架
| 框架 | 开发者 | 特点 | Agent | Harness | Loop |
|---|---|---|---|---|---|
| LangChain | LangChain | 最流行的Agent框架 | ✅ | ✅ | ✅ |
| LangGraph | LangChain | 基于图的Agent编排 | ✅ | ✅ | ✅ |
| AutoGen | Microsoft | 多Agent对话框架 | ✅ | ✅ | ✅ |
| CrewAI | CrewAI | 角色扮演多Agent | ✅ | ✅ | ✅ |
| Claude Code | Anthropic | CLI编程Agent | ✅ | ✅ | ✅ |
| Cursor | Cursor | IDE编程Agent | ✅ | ✅ | ✅ |
| Devin | Cognition | 自主编程Agent | ✅ | ✅ | ✅ |
| OpenAI Agents SDK | OpenAI | OpenAI官方Agent框架 | ✅ | ✅ | ✅ |
17.2 LangChain Agent
LangChain是最流行的Agent开发框架。
核心组件：
· LLM：大语言模型（如GPT-4, Claude）
· Tools：工具列表（搜索、计算、API等）
· Agent：决策器（决定用什么工具）
· AgentExecutor：执行器（管理Agent Loop）
代码示例：
from langchain.agents import AgentExecutor, create_react_agent
from langchain_openai import ChatOpenAI
from langchain.tools import Tool
# 定义工具
tools = [
Tool(name="Search", func=search_func, description="搜索互联网"),
Tool(name="Calculator", func=calc_func, description="数学计算"),
]
# 创建Agent
llm = ChatOpenAI(model="gpt-4")
agent = create_react_agent(llm, tools, prompt)
# 创建执行器（包含Agent Loop）
executor = AgentExecutor(agent=agent, tools=tools, max_iterations=10)
# 运行
result = executor.invoke({"input": "北京今天天气怎么样？"})
17.3 Claude Code（Anthropic的编程Agent）
Claude Code是一个命令行编程Agent。
架构特点：
· Agent：Claude（Anthropic的LLM）
· Harness：命令行环境 + 文件系统 + 终端
· Loop：Think → Act(工具调用) → Observe → 循环
可用工具：
· read_file：读取文件
· write_file：写入文件
· edit_file：编辑文件
· run_command：执行终端命令
· search_files：搜索文件内容
· list_files：列出目录文件
Loop流程：
用户输入任务 → Claude思考 → 调用工具 → 获取结果 → 继续思考 → ...
直到任务完成或达到限制
17.4 OpenAI Agents SDK
OpenAI官方的Agent开发框架。
核心概念：
· Agent：智能体，配置LLM + 工具 + 指令
· Tool：工具，Agent可以调用的功能
· Handoff：交接，Agent之间的任务传递
· Guardrail：护栏，输入输出的安全检查
· Runner：运行器，管理Agent Loop
代码示例：
from openai import Agent, Tool, Runner
agent = Agent(
name="Assistant",
instructions="你是一个有帮助的助手",
model="gpt-4",
tools=[
Tool(function=search_web),
Tool(function=run_code),
]
)
result = Runner.run(agent, "帮我分析这份数据")
第18章 实战案例
18.1 案例一：数据分析Agent
任务："分析sales.csv数据，找出最畅销的产品，生成可视化图表"
Agent Loop流程：
第1轮（理解任务）：
Think: 需要读取CSV文件，分析数据，生成图表
Act: read_file("sales.csv")
Observe: 文件内容（前几行数据）
第2轮（数据探索）：
Think: 数据包含product_name, quantity, price列
Act: run_code("import pandas as pd; df = pd.read_csv('sales.csv'); print(df.describe())")
Observe: 数据统计摘要
第3轮（分析计算）：
Think: 需要按产品汇总销量
Act: run_code("top_products = df.groupby('product_name')['quantity'].sum().sort_values(ascending=False).head(10)")
Observe: 最畅销的10个产品
第4轮（生成图表）：
Think: 用matplotlib生成柱状图
Act: run_code("import matplotlib.pyplot as plt; ... plt.savefig('top_products.png')")
Observe: 图表已保存
第5轮（生成报告）：
Think: 写一份分析报告
Act: write_file("report.md", "# 销售数据分析报告n...")
Observe: 报告已生成
Judge: 任务完成
18.2 案例二：网站开发Agent
任务："创建一个个人博客网站，包含首页、文章列表和关于页面"
Plan阶段：
Agent制定计划：
1. 创建项目结构
2. 创建首页(index.html)
3. 创建文章列表页(articles.html)
4. 创建关于页面(about.html)
5. 创建CSS样式
6. 创建JavaScript交互
7. 测试运行
Execute阶段（每步一个Loop）：
Loop 1-7: 逐步创建各文件
Loop 8: 测试运行，发现问题
Loop 9-10: 修复问题
Loop 11: 最终验证
输出：
完整的博客网站代码，包含所有页面和样式
第六篇：AI Coding深度篇——Harness Engineering在AI编程中的实践
本篇是整份文档的核心补充。AI Coding是Agent+Harness+Loop最成熟的应用场景，Harness Engineering在这个领域有最深入的实践和最清晰的方法论。
第21章 AI Coding的演进：从补全到Agent
21.1 AI Coding的四个阶段
阶段一：代码补全（2021-2022）
代表：GitHub Copilot（基于Codex）
能力：根据上下文预测下一行代码
交互：Tab键接受建议
局限：只能补全，不能理解意图
阶段二：代码对话（2023）
代表：ChatGPT + Code Interpreter, Cursor Chat
能力：用自然语言描述需求，AI生成代码片段
交互：对话式，一问一答
局限：需要人工复制粘贴代码，不能自主执行
阶段三：代码Agent（2024）
代表：Cursor Agent, Claude Code, Windsurf
能力：自主规划、编写、测试、调试代码
交互：给一个目标，Agent自主完成
突破：从"写代码"变成"完成项目"
阶段四：自主开发（2025+）
代表：Devin, OpenHands, Claude Code with MCP
能力：端到端完成软件开发任务
交互：描述需求 → Agent完成全部工作
目标：替代初级开发者的工作
21.2 AI Coding Agent的核心能力
一个完整的AI Coding Agent需要：
1. 理解需求
· 理解自然语言描述的功能需求
· 理解已有代码的结构和逻辑
· 理解项目的技术栈和约束
2. 代码生成
· 生成符合项目风格的代码
· 处理多文件联动修改
· 生成测试用例
3. 代码执行
· 运行代码验证正确性
· 执行测试套件
· 启动开发服务器
4. 调试修复
· 分析错误信息
· 定位问题根源
· 自动修复bug
5. 环境操作
· 安装依赖包
· 配置环境变量
· 操作文件系统
· 使用Git进行版本控制
6. 持续迭代
· 根据反馈修改代码
· 优化性能
· 重构代码
第22章 Harness Engineering：AI Coding的核心方法论
22.1 什么是Harness Engineering
Harness Engineering = 设计和构建AI Coding Agent运行环境的工程实践
核心问题：
给定一个LLM（如Claude, GPT-4），如何构建一个环境，
让它能够像一个真正的开发者一样工作？
这个环境（Harness）需要解决：
· Agent能看到什么？（上下文：代码库、文件、终端输出）
· Agent能做什么？（工具：读写文件、执行命令、搜索代码）
· Agent的安全边界在哪？（权限：哪些目录可写、哪些命令可执行）
· Agent的行为如何引导？（系统提示：角色定义、编码规范、工作流程）
22.2 Harness Engineering的五大支柱
┌─────────────────────────────────────────────────────────────┐
│ Harness Engineering │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 1.上下文工程 │ │ 2.工具工程 │ │ 3.提示工程 │ │
│ │ Context │ │ Tools │ │ Prompt │ │
│ │ Engineering │ │ Engineering│ │ Engineering│ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ 4.权限工程 │ │ 5.反馈工程 │ │
│ │ Permission │ │ Feedback │ │
│ │ Engineering │ │ Engineering│ │
│ └─────────────┘ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
22.3 支柱一：上下文工程（Context Engineering）
上下文工程是Harness Engineering中最核心、最被低估的部分。
上下文工程 = 决定"把什么信息放入Agent的上下文窗口"
上下文窗口是Agent的"工作记忆"：
· 太少信息 → Agent不了解项目，做出错误决策
· 太多信息 → 超出窗口限制，或者噪声干扰推理
· 错误信息 → Agent被误导，产生幻觉
上下文工程的核心挑战：
LLM的上下文窗口有限（如200K token）
但一个代码项目可能有数百万行代码
如何从海量代码中选出最关键的信息？
上下文的四大来源：
来源一：系统提示（System Prompt）
· Agent的角色定义（"你是一个资深Python开发者"）
· 行为规范（"修改文件前先读取当前内容"）
· 编码规范（"使用TypeScript严格模式"）
· 项目约定（"本项目使用pnpm作为包管理器"）
来源二：用户输入（User Input）
· 用户的任务描述
· 用户的补充说明
· 用户的反馈和修正
来源三：代码库上下文（Codebase Context）
· 当前打开的文件
· 相关的依赖文件
· 项目结构概览
· Git历史（最近的提交、变更）
来源四：工具输出（Tool Output）
· 文件读取的结果
· 命令执行的输出
· 搜索的结果
· 错误信息
上下文选择策略：
策略一：基于相关性的选择
· 分析用户问题涉及哪些文件
· 只加载相关文件的内容
· 使用AST（抽象语法树）分析代码依赖关系
策略二：基于层次的选择
· 第一层：当前文件（完整内容）
· 第二层：直接依赖文件（完整内容）
· 第三层：间接依赖文件（只加载函数签名）
· 第四层：项目结构概览（目录树+文件描述）
策略三：基于时间的选择
· 最近修改的文件（可能与当前任务相关）
· 最近查看的文件（用户关注的区域）
· Git最近的变更（了解项目最新状态）
策略四：基于搜索的选择
· 用户提到的关键词 → 搜索代码库
· 错误信息中的文件名 → 加载相关文件
· 测试失败的堆栈 → 加载相关代码
上下文压缩技术：
当上下文超出窗口限制时，需要压缩：
技术一：摘要压缩
将长文件压缩为关键信息：
原始：1000行的utils.py
压缩："utils.py包含以下函数：
- formatDate(date): 格式化日期
- validateEmail(email): 邮箱验证
- debounce(fn, delay): 防抖函数
- throttle(fn, limit): 节流函数"
技术二：差异压缩
只展示修改前后的差异，而非完整文件：
原始：修改前完整文件 + 修改后完整文件
压缩：只展示变更的行和上下文
技术三：按需加载
不预加载所有文件，当Agent需要时再加载：
Agent: "我需要查看auth.ts的内容"
Harness: [加载auth.ts并注入上下文]
技术四：层次化摘要
对于大型代码库，提供多层次的概览：
Level 0: 项目描述（1段话）
Level 1: 目录结构（文件夹+文件名）
Level 2: 模块概述（每个文件的函数列表）
Level 3: 完整代码（按需加载）
22.4 支柱二：工具工程（Tools Engineering）
工具工程 = 设计Agent可以使用的工具集
AI Coding Agent的典型工具集：
┌─────────────────────────────────────────────────┐
│ AI Coding 工具集 │
│ │
│ 文件操作： │
│ · read_file(path) → 文件内容 │
│ · write_file(path, content) → 创建/覆盖文件 │
│ · edit_file(path, old, new) → 精确编辑 │
│ · list_files(dir) → 目录结构 │
│ · search_files(pattern) → 搜索文件内容 │
│ │
│ 代码执行： │
│ · run_command(cmd) → 执行终端命令 │
│ · run_test(test_path) → 运行测试 │
│ · start_server(port) → 启动开发服务器 │
│ │
│ 代码分析： │
│ · get_definitions(file) → 获取函数/类定义 │
│ · find_references(symbol) → 查找引用 │
│ · get_diagnostics(file) → 获取错误/警告 │
│ │
│ 版本控制： │
│ · git_diff() → 查看变更 │
│ · git_commit(msg) → 提交代码 │
│ · git_log(n) → 查看提交历史 │
│ │
│ 网络访问： │
│ · web_search(query) → 搜索互联网 │
│ · fetch_url(url) → 获取网页内容 │
│ │
└─────────────────────────────────────────────────┘
工具设计的关键原则：
原则一：原子性
每个工具只做一件事
好：read_file, write_file, edit_file（三个工具）
差：manage_file(action, ...)(一个工具做三件事)
原则二：自描述性
工具的描述要让Agent清楚知道何时使用
好："edit_file: 精确编辑文件中的特定内容。
适用于修改少量代码行。
输入：文件路径、要查找的原文、替换的新文。
注意：原文必须与文件内容完全匹配。"
差："edit_file: 编辑文件"
原则三：安全性
危险操作要有保护机制
· write_file: 覆盖前检查文件是否已存在
· run_command: 某些命令（rm -rf）需要确认
· git_commit: 提交前显示diff
原则四：反馈性
工具执行后要返回清晰的结果
成功："文件已保存到 /src/app.ts"
失败："错误：权限不足，无法写入 /etc/config"
警告："文件已存在，将被覆盖"
原则五：组合性
工具可以组合使用完成复杂任务
例如：search_files找到位置 → read_file读取内容 → edit_file修改代码
22.5 支柱三：提示工程（Prompt Engineering for Coding）
AI Coding的提示工程有其特殊性：
系统提示的结构：
┌──────────────────────────────────────────────┐
│ 角色定义 │
│ "你是一个资深的全栈开发者，精通TypeScript、 │
│ React、Node.js。你注重代码质量和最佳实践。" │
├──────────────────────────────────────────────┤
│ 项目上下文 │
│ "这是一个Next.js 14项目，使用App Router。 │
│ 数据库是PostgreSQL，ORM使用Prisma。 │
│ 包管理器是pnpm。" │
├──────────────────────────────────────────────┤
│ 编码规范 │
│ "· 使用TypeScript严格模式 │
│ · 组件使用函数式写法 │
│ · 异步操作使用async/await │
│ · 错误处理使用try-catch │
│ · 变量命名使用camelCase │
│ · 组件命名使用PascalCase" │
├──────────────────────────────────────────────┤
│ 工作流程 │
│ "1. 修改文件前，先读取当前内容 │
│ 2. 修改后，运行相关测试验证 │
│ 3. 如果测试失败，分析原因并修复 │
│ 4. 完成后，总结修改内容" │
├──────────────────────────────────────────────┤
│ 安全规则 │
│ "· 不要删除用户数据 │
│ · 不要修改.env文件中的敏感信息 │
│ · 执行rm命令前要确认 │
│ · 不要提交包含密钥的代码" │
└──────────────────────────────────────────────┘
上下文注入的最佳实践：
实践一：动态注入工具列表
不要在系统提示中硬编码工具列表
而是在每次请求时动态注入当前可用的工具
原因：
· 工具列表可能变化
· 不同场景下可用工具不同
· 减少系统提示的长度
实践二：注入相关代码片段
当用户提到某个文件或函数时，
自动将相关代码注入上下文
用户："修改UserService的login方法"
→ 自动注入：UserService.ts的完整内容
实践三：注入错误信息
当代码执行失败时，
将完整的错误信息（包括堆栈）注入上下文
这帮助Agent：
· 理解错误的类型
· 定位错误的位置
· 分析错误的原因
实践四：注入测试结果
运行测试后，
将测试结果注入上下文
通过：3个测试通过
失败：test_login - AssertionError: expected 200, got 401
→ Agent知道需要修复login相关的代码
22.6 支柱四：权限工程（Permission Engineering）
权限工程 = 定义Agent的安全边界
AI Coding Agent的权限矩阵：
┌──────────────┬────────────┬────────────┬────────────┐
│ 操作 │ 只读目录 │ 项目目录 │ 系统目录 │
├──────────────┼────────────┼────────────┼────────────┤
│ 读取文件 │ ✅ │ ✅ │ ⚠️ │
│ 写入文件 │ ❌ │ ✅ │ ❌ │
│ 执行命令 │ ⚠️ │ ✅ │ ❌ │
│ 安装依赖 │ ❌ │ ✅ │ ❌ │
│ 删除文件 │ ❌ │ ⚠️ │ ❌ │
│ 网络访问 │ ✅ │ ✅ │ ⚠️ │
└──────────────┴────────────┴────────────┴────────────┘
✅ 允许 ⚠️ 需要确认 ❌ 禁止
确认机制的设计：
危险操作前暂停，等待用户确认
Agent: "我需要删除 temp/ 目录下的所有文件"
Harness: "⚠️ 即将执行：rm -rf temp/*
这将删除以下文件：
- temp/cache.json
- temp/debug.log
确认执行？(y/n)"
用户: "y"
Harness: [执行命令]
22.7 支柱五：反馈工程（Feedback Engineering）
反馈工程 = 设计Agent如何获取和利用执行反馈
反馈的类型：
1. 编译/运行反馈
代码执行后的输出：
· 成功：程序正常运行，输出结果
· 失败：编译错误、运行时异常
· 警告：类型警告、弃用警告
2. 测试反馈
测试执行后的结果：
· 通过：所有测试通过
· 失败：哪些测试失败，失败原因
· 覆盖率：代码覆盖率报告
3. 静态分析反馈
Lint和类型检查的结果：
· ESLint警告/错误
· TypeScript类型错误
· 代码风格问题
4. 用户反馈
用户对Agent工作的评价：
· "这个实现不对，应该用..."
· "好的，继续下一步"
· "这里有个bug"
反馈的利用策略：
策略一：错误驱动的迭代
错误 → 分析原因 → 修复 → 重新验证
例子：
TypeError: Cannot read property 'name' of undefined
→ Agent分析：user对象可能是null
→ 修复：添加空值检查 if (user?.name)
→ 重新运行：通过
策略二：测试驱动的开发
先写测试 → 测试失败 → 写代码使测试通过
例子：
Agent: 写一个login函数的测试
测试：expect(login('user', 'pass')).toBe(true)
运行：失败（login函数不存在）
Agent: 实现login函数
运行：通过
策略三：渐进式完善
先实现基本功能 → 根据反馈逐步完善
例子：
v1: 实现基本的登录功能
反馈：缺少错误处理
v2: 添加try-catch和错误提示
反馈：没有输入验证
v3: 添加邮箱格式验证和密码强度检查
第23章 主流AI Coding Agent深度对比
23.1 Cursor
定位：AI-native IDE（AI原生集成开发环境）
架构：
· 编辑器：基于VS Code
· Agent：内置AI Coding Agent
· Harness：VS Code的文件系统 + 终端 + 扩展
· Loop：Think → Act(工具调用) → Observe
特色功能：
· Tab补全：类似Copilot的代码补全
· Chat：对话式代码问答
· Agent：自主完成编程任务
· Composer：多文件协同编辑
· Cmd+K：选中代码后用自然语言修改
Harness特点：
· 上下文：自动索引整个代码库，支持语义搜索
· 工具：read_file, write_file, edit_file, terminal, search
· 权限：写入项目目录，终端命令需确认
· 模型：支持GPT-4, Claude等多个模型
23.2 Claude Code
定位：命令行AI编程Agent
架构：
· 界面：命令行CLI
· Agent：Claude（Anthropic的LLM）
· Harness：文件系统 + 终端 + MCP协议
· Loop：Think → Act → Observe → 循环
特色功能：
· 直接在终端中运行
· 可以执行任意终端命令
· 支持MCP（Model Context Protocol）扩展工具
· 支持多Agent协作
Harness特点：
· 上下文：自动读取项目文件，支持CLAUDE.md配置文件
· 工具：read_file, write_file, edit_file, run_command, search
· 权限：细粒度的权限控制（可配置哪些命令需要确认）
· MCP：可以通过MCP协议接入外部工具和数据源
23.3 Windsurf (Codeium)
定位：AI编程助手+Agent
架构：
· 编辑器：基于VS Code
· Agent：Cascade（Windsurf的AI Agent）
· Harness：VS Code环境
· Loop：Flow模式（连续执行多步）
特色功能：
· Cascade：多步骤自主编程
· 内联编辑：在代码中直接用自然语言修改
· 终端集成：可以直接在终端中执行命令
· 上下文感知：自动理解项目结构
Harness特点：
· 上下文：代码库索引 + 终端历史 + Git状态
· 工具：文件操作 + 终端 + 搜索 + Git
· 权限：可配置的安全边界
23.4 Devin (Cognition)
定位：自主AI软件工程师
架构：
· 界面：Web界面 + 云环境
· Agent：自主编程Agent
· Harness：完整的开发环境（编辑器+终端+浏览器+沙箱）
· Loop：长时间自主运行
特色功能：
· 完整的开发环境：不只是代码编辑，还有浏览器、终端
· 自主规划：可以理解需求并制定开发计划
· 长时间运行：可以持续工作数小时
· 环境管理：自动安装依赖、配置环境
Harness特点：
· 上下文：完整的项目上下文 + 网页搜索
· 工具：文件操作 + 终端 + 浏览器 + 部署
· 权限：沙箱环境，安全隔离
· 持久化：可以记住之前的对话和决策
23.5 对比总结
| 维度 | Cursor | Claude Code | Windsurf | Devin |
|---|---|---|---|---|
| 界面 | IDE | CLI | IDE | Web |
| 自主性 | 中 | 高 | 中 | 最高 |
| 工具丰富度 | 高 | 高 | 中 | 最高 |
| 上下文能力 | 强 | 强 | 中 | 强 |
| 价格 | $20/月 | 按token | 免费/付费 | $500/月 |
| 适用场景 | 日常开发 | 脚本/自动化 | 日常开发 | 独立项目 |
| 学习曲线 | 低 | 中 | 低 | 低 |
第24章 MCP协议：Harness的标准化
24.1 什么是MCP
MCP = Model Context Protocol（模型上下文协议）
由Anthropic提出，目标是标准化AI Agent与外部工具/数据源的交互方式。
类比：
USB是电脑与外设的标准接口
MCP是AI Agent与工具/数据的标准接口
MCP解决的问题：
之前：每个AI应用都要自己实现工具调用的接口
现在：工具开发者按照MCP标准开发一次，所有支持MCP的Agent都能使用
24.2 MCP的架构
┌─────────────────────────────────────────────┐
│ MCP Host │
│ （AI应用，如Claude Code） │
│ │
│ ┌─────────────┐ │
│ │ MCP Client │ │
│ └──────┬──────┘ │
│ │ │
└─────────┼───────────────────────────────────┘
│ MCP协议
│
┌─────────▼───────────────────────────────────┐
│ MCP Server │
│ （工具/数据源提供者） │
│ │
│ ┌───────────┐ ┌───────────┐ ┌───────────┐ │
│ │ Tools │ │ Resources │ │ Prompts │ │
│ │ │ │ │ │ │ │
│ │ · 搜索 │ │ · 数据库 │ │ · 模板 │ │
│ │ · API调用 │ │ · 文件系统 │ │ · 提示词 │ │
│ │ · 数据处理 │ │ · API数据 │ │ │ │
│ └───────────┘ └───────────┘ └───────────┘ │
│ │
└─────────────────────────────────────────────┘
24.3 MCP提供的三种能力
1. Tools（工具）
Agent可以调用的功能
示例：
{
"name": "query_database",
"description": "查询数据库",
"parameters": {
"sql": { "type": "string", "description": "SQL查询语句" }
}
}
2. Resources（资源）
Agent可以读取的数据源
示例：
{
"uri": "file:///project/README.md",
"name": "项目说明",
"mimeType": "text/markdown"
}
3. Prompts（提示模板）
预定义的提示词模板
示例：
{
"name": "code_review",
"description": "代码审查模板",
"arguments": [
{ "name": "code", "description": "要审查的代码" }
]
}
24.4 MCP的实际应用
场景：Claude Code + 数据库MCP Server
1. 安装MCP Server：
npm install -g @modelcontextprotocol/server-postgres
2. 配置Claude Code：
claude mcp add postgres -- npx @modelcontextprotocol/server-postgres postgresql://localhost/mydb
3. 使用：
用户："查询用户表中最近注册的10个用户"
Agent思考：需要使用数据库查询工具
Agent行动：调用query_database工具
SQL: SELECT * FROM users ORDER BY created_at DESC LIMIT 10
Agent观察：获取到10条用户记录
Agent回答："最近注册的10个用户是：..."
效果：
Agent可以直接访问数据库，无需用户手动复制SQL结果
Agent可以根据查询结果做进一步分析
第25章 AI Coding的最佳实践
25.1 如何写好系统提示
好的AI Coding系统提示模板：
## 角色
你是一个资深的[技术栈]开发者，专注于[领域]。
## 项目上下文
- 项目名称：[名称]
- 技术栈：[框架、语言、数据库等]
- 包管理器：[npm/pnpm/yarn]
- 代码风格：[ESLint/Prettier配置]
## 编码规范
- [具体的编码规范列表]
## 工作流程
1. 理解任务需求
2. 阅读相关代码
3. 制定修改计划
4. 执行修改
5. 运行测试验证
6. 总结修改内容
## 安全规则
- 不要删除用户数据
- 不要修改配置文件中的敏感信息
- 危险操作前要确认
## 可用工具
[工具列表会在运行时注入]
25.2 CLAUDE.md / .cursorrules 配置
项目级配置文件，定义AI Agent的行为规范：
# CLAUDE.md 示例
## 项目概述
这是一个Next.js 14电商项目，使用TypeScript + Tailwind CSS。
## 技术栈
- 框架：Next.js 14 (App Router)
- 语言：TypeScript (strict mode)
- 样式：Tailwind CSS
- 数据库：PostgreSQL + Prisma
- 包管理：pnpm
## 代码规范
- 组件使用函数式写法 + hooks
- 异步操作使用async/await
- 错误处理使用try-catch
- 变量命名：camelCase
- 组件命名：PascalCase
- 文件命名：kebab-case
## 项目结构
/src
/app - Next.js App Router页面
/components - React组件
/lib - 工具函数和配置
/types - TypeScript类型定义
/prisma - 数据库Schema
## 常用命令
- pnpm dev: 启动开发服务器
- pnpm build: 构建生产版本
- pnpm test: 运行测试
- pnpm lint: 代码检查
## 注意事项
- 不要修改/prisma/migrations目录
- API路由放在/app/api目录下
- 环境变量使用.env.local
25.3 有效使用AI Coding Agent的技巧
技巧一：提供足够的上下文
差："帮我修复这个bug"
好："登录页面的表单提交后没有反应。
文件是src/app/login/page.tsx
控制台报错：TypeError: Cannot read property 'email' of undefined
使用的是Next.js 14 App Router"
技巧二：分步骤给任务
差："帮我做一个完整的用户管理系统"
好："第一步：创建用户的数据库Schema（Prisma）
第二步：创建用户的API路由（CRUD）
第三步：创建用户的前端页面"
技巧三：明确期望的输出
差："写一个函数处理数据"
好："写一个函数：
- 输入：用户数组 [{id, name, email}]
- 输出：按注册时间排序的活跃用户列表
- 要求：过滤掉未验证邮箱的用户"
技巧四：利用Agent的测试能力
让Agent先写测试，再写实现：
"请为login函数编写单元测试，然后实现这个函数使测试通过"
技巧五：让Agent解释代码
不只是让Agent写代码，也让它解释：
"解释一下这个middleware的作用，以及为什么这样设计"
技巧六：使用Agent进行代码审查
"审查这段代码，找出潜在的问题和改进建议"
25.4 AI Coding的常见陷阱
陷阱一：过度依赖
问题：完全依赖AI写代码，自己不理解代码逻辑
后果：代码出了问题无法调试，无法维护
建议：始终理解AI生成的代码，必要时让它解释
陷阱二：忽视测试
问题：AI写了代码但没有测试，直接上线
后果：线上bug频发
建议：要求AI同时写测试，或者自己补充测试
陷阱三：不检查安全性
问题：AI生成的代码可能有安全漏洞
后果：SQL注入、XSS攻击等安全问题
建议：让AI检查代码安全性，或者使用安全扫描工具
陷阱四：上下文不足
问题：没有给AI足够的项目上下文
后果：AI生成的代码不符合项目规范
建议：配置好CLAUDE.md或.cursorrules，提供项目上下文
陷阱五：提示词模糊
问题：任务描述不清晰
后果：AI理解错误，生成错误的代码
建议：提供明确的需求、输入输出、约束条件
第26章 AI Coding的未来趋势
26.1 趋势一：从辅助到自主
当前：AI辅助开发者写代码（人是主导）
未来：AI自主完成开发任务（AI是主导，人是监督）
演进路径：
2023：AI补全代码（Tab键接受）
2024：AI生成代码片段（对话式）
2025：AI自主完成单个任务（Agent模式）
2026：AI自主完成整个项目（自主开发）
2027+：AI管理软件生命周期（开发+维护+优化）
26.2 趋势二：Harness标准化
当前：每个AI Coding工具自己实现Harness
未来：标准化的Harness协议（如MCP）
标准化的好处：
· 工具开发者只需实现一次，所有Agent都能用
· 用户可以在不同Agent之间切换，工具生态共享
· 降低AI Coding工具的开发成本
26.3 趋势三：多Agent协作开发
当前：单个Agent完成所有工作
未来：多个专业Agent协作
分工示例：
· 需求Agent：分析用户需求，生成技术方案
· 架构Agent：设计系统架构，定义接口
· 编码Agent：编写具体代码
· 测试Agent：编写和运行测试
· 审查Agent：代码审查，找出问题
· 部署Agent：配置环境，部署上线
26.4 趋势四：AI原生开发工具
当前：AI功能嵌入传统IDE（如VS Code + Copilot）
未来：AI原生的开发工具（从底层设计就为AI服务）
AI原生的特点：
· 代码结构为AI优化（更易理解）
· 文档为AI生成和维护
· 测试由AI自动编写
· 重构由AI自动执行
· 版本控制由AI管理
第七篇：前沿与展望（原第六篇）
第七篇：前沿与展望
第19章 当前挑战
19.1 可靠性问题
Agent可能犯错，而且错误会在Loop中累积。
问题：
· LLM可能产生错误的推理
· 工具调用可能失败
· 错误的行动可能破坏环境
· 复杂任务的成功率还不够高
缓解方法：
· 人在回路（Human-in-the-loop）：关键步骤需要人类确认
· 沙箱执行：在隔离环境中执行，防止破坏
· 回滚机制：出错时可以恢复到之前的状态
· 多Agent验证：让一个Agent检查另一个Agent的输出
19.2 效率问题
Agent Loop的每一轮都需要LLM推理，成本高、速度慢。
问题：
· 每轮Loop消耗一次LLM调用（成本）
· LLM推理需要时间（延迟）
· 复杂任务需要很多轮Loop（总成本高）
优化方法：
· 使用更小更快的模型（如GPT-4o-mini）
· 减少不必要的Loop轮次
· 并行执行独立的工具调用
· 缓存重复的工具调用结果
19.3 安全问题
Agent能执行代码和操作文件，存在安全风险。
问题：
· 恶意指令可能导致Agent执行危险操作
· Agent可能泄露敏感信息
· 工具调用可能被滥用
防护措施：
· 最小权限原则：只给Agent完成任务所需的最小权限
· 沙箱隔离：在容器或虚拟机中执行
· 输入验证：检查Agent的输出是否安全
· 审计日志：记录所有操作以便追溯
第20章 未来趋势
20.1 趋势一：更自主的Agent
当前：Agent需要人类频繁指导和确认
未来：Agent能独立完成复杂项目
关键进展：
· 更强的推理能力（减少错误）
· 更好的规划能力（处理复杂任务）
· 更可靠的工具使用（减少失败）
· 更强的自我纠错能力
20.2 趋势二：多Agent协作
当前：主要是单Agent模式
未来：多个专业Agent协作完成任务
就像一个公司：
· CEO Agent：负责战略规划
· PM Agent：负责项目管理
· Dev Agent：负责开发
· QA Agent：负责测试
· Ops Agent：负责部署
20.3 趋势三：Agent即服务
当前：Agent需要开发者自己搭建
未来：Agent作为云服务提供
用户只需要：
· 描述任务
· Agent自动完成
· 无需关心底层架构
代表趋势：
· Claude Code, Cursor等编程Agent
· 各类垂直领域Agent（法律、医疗、金融...）
· Agent平台（提供Agent创建和管理服务）
20.4 趋势四：具身Agent
当前：Agent主要在数字世界中工作（写代码、操作文件）
未来：Agent能控制物理设备（机器人、无人机、智能家居）
VLA（Vision-Language-Action）就是这个方向的前沿：
Agent不仅"想"，还能"做"
从数字世界延伸到物理世界
附录
附录A：核心术语表
| 术语 | 英文 | 解释 |
|---|---|---|
| Agent | Agent | 能自主行动的AI智能体 |
| Harness | Harness | Agent的工具箱和运行环境 |
| Loop | Agent Loop | Agent的思考-行动-观察-判断循环 |
| Tool | Tool | Agent可以调用的具体功能 |
| Skill | Skill | 预定义的任务能力模块 |
| Context | Context | Agent可用的上下文信息 |
| System Prompt | System Prompt | 定义Agent角色和行为的指令 |
| ReAct | Reasoning+Acting | 推理与行动交替的Agent模式 |
| Grounding | Grounding | 让AI输出基于事实而非幻觉 |
| Orchestration | Orchestration | 多Agent的协调编排 |
| Sandbox | Sandbox | 隔离的安全执行环境 |
| Handoff | Handoff | Agent之间的任务交接 |
| Guardrail | Guardrail | 输入输出的安全护栏 |
| Token | Token | LLM处理的最小文本单元 |
| Hallucination | Hallucination | AI产生不实信息的现象 |
| Chain of Thought | CoT | 让AI展示推理过程的技术 |
| Few-shot | Few-shot | 通过少量示例引导AI |
| Embedding | Embedding | 将文本/图像转化为向量表示 |
附录B：推荐学习资源
入门：
- LangChain官方文档（langchain.com）——最流行的Agent框架
- OpenAI Agents SDK文档——OpenAI官方方案
- “Building Effective Agents”（Anthropic博客）——Agent设计最佳实践
进阶：
4. “ReAct: Synergizing Reasoning and Acting”（论文）——Agent Loop的经典论文
5. “Toolformer: Language Models Can Teach Themselves to Use Tools”（论文）——工具使用
6. LangGraph文档——基于图的Agent编排
前沿：
7. “Agent Protocol”（agentprotocol.ai）——Agent通信标准
8. CrewAI文档——多Agent协作框架
9. AutoGen文档——微软的多Agent框架
附录C：推荐学习路径
第一阶段：理解概念（1-2天）
- 理解LLM的基本原理
- 理解Agent、Harness、Loop的概念和关系
- 了解ReAct模式
第二阶段：动手实践（1-2周）
4. 使用LangChain创建第一个Agent
5. 为Agent添加工具（搜索、计算等）
6. 观察Agent Loop的执行过程
第三阶段：深入学习（2-4周）
7. 学习Harness的设计原则
8. 实现自定义工具
9. 学习多Agent协作模式
10. 研究错误处理和安全机制
第四阶段：实战项目（持续）
11. 构建一个完整的Agent应用
12. 优化Agent的性能和可靠性
13. 探索垂直领域Agent
14. 跟踪最新研究进展
© 版权声明
文章版权归作者所有，未经允许请勿转载。
