Agent Prompt 工程入门

Agent Prompt 工程入门：如何让 AI 不只是“回答问题”，而是真正“执行任务”

最近在学习和实践 AI Agent，发现一个很有意思的问题：

为什么同样是给 AI 一段 Prompt，有的 AI 只能回答问题，有的 Agent 却可以自己分析代码、调用工具、修改文件、运行测试，最后完成一个完整任务？

其中一个很重要的原因，就是 Prompt Engineering（提示词工程）。

这篇文章不讨论复杂的论文和算法，只从实际开发的角度，简单理解一下 Agent Prompt 工程到底是什么，以及它和普通 Prompt 有什么区别。

一、先理解什么是 Prompt

Prompt 可以简单理解成：

告诉 AI 你希望它做什么。

比如：

帮我写一个登录页面。

AI 根据这句话生成代码。

再具体一点：

使用 Vue3 + TypeScript 帮我写一个登录页面，
包含用户名、密码、登录按钮和表单校验。

AI 得到的信息更多，生成的结果通常也会更符合要求。

所以最简单的理解：

Prompt
    ↓
告诉 AI 要做什么
    ↓
AI 返回结果

这种方式对于普通聊天场景已经够用了。

但是 Agent 不一样。

二、普通 AI 和 Agent 有什么区别？

普通 AI 更多是在：

用户
 ↓
Prompt
 ↓
LLM
 ↓
回答

例如：

帮我写一个 Vue 登录页面。

AI 把代码生成出来，任务基本就结束了。

而 Agent 更像这样：

用户
 ↓
Prompt
 ↓
Agent
 ↓
理解任务
 ↓
制定执行计划
 ↓
调用工具
 ↓
获取结果
 ↓
继续执行
 ↓
验证结果
 ↓
必要时修复
 ↓
最终结果

例如用户说：

帮我修复项目里的登录 Bug。

一个 Agent 可能会：

1. 分析项目结构
2. 查找登录相关代码
3. 阅读 Login.vue
4. 查找登录接口
5. 分析 Bug 原因
6. 修改代码
7. 运行 TypeScript 检查
8. 发现新的类型错误
9. 修复类型错误
10. 再次检查
11. 告诉用户修改结果

这时候 Prompt 就不能只负责：

“告诉 AI 最终要什么。”

还需要帮助 Agent 理解：

应该怎么做，以及什么情况下才算完成。

三、Agent Prompt 和普通 Prompt 的区别

可以用一个非常简单的例子理解。

普通 Prompt

帮我开发一个登录页面。

它只告诉 AI：

我要什么。

Agent Prompt

你是一名前端开发工程师。

任务：
开发一个登录页面。

要求：
1. 先检查项目使用的技术栈
2. 查找项目中是否已经存在登录相关组件
3. 优先复用已有组件
4. 完成代码修改
5. 运行 TypeScript 检查
6. 如果出现错误，定位并修复
7. 再次执行验证
8. 最后总结修改内容

这时候 Prompt 已经开始描述：

你是谁
↓
你要做什么
↓
你应该怎么做
↓
有什么限制
↓
怎么验证

这就是 Agent Prompt 和普通 Prompt 一个非常重要的区别。

四、Agent Prompt 最重要的几个部分

在实际 Agent 开发中，可以把 Prompt 简单拆成几个部分：

Role
 ↓
Context
 ↓
Goal
 ↓
Rules
 ↓
Workflow
 ↓
Tools
 ↓
Validation
 ↓
Output

并不是每个 Prompt 都必须包含所有部分，但是这个结构非常适合我们理解 Agent Prompt。

五、Role：告诉 Agent 你是谁

首先告诉 Agent：

你应该以什么角色来完成任务。

例如：

你是一名前端开发工程师。

或者：

你是一名 React 项目代码维护 Agent。

为什么要定义角色？

因为不同角色关注的问题不一样。

比如：

你是一名 UI 设计师。

可能更关注：

  • 页面布局
  • 颜色
  • 间距
  • 视觉效果

而：

你是一名前端工程师。

可能更关注：

  • 组件复用
  • TypeScript
  • 状态管理
  • 性能
  • 可维护性

所以 Role 的作用可以简单理解为：

给 Agent 一个工作身份。

六、Context：告诉 Agent 当前环境

Agent 不能只知道自己是谁，还需要知道：

自己现在正在什么环境里工作。

比如一个前端项目：

项目技术栈：

- React 19
- TypeScript
- Vite
- Zustand

项目规范：

- 使用函数组件
- 优先复用已有组件
- 不直接操作 DOM
- 不随意增加依赖

这些信息就是 Context。

Context 可以理解成：

完成任务所需要的背景信息。

例如在 Claude Code 中，CLAUDE.md 就经常被用来提供项目相关的上下文、开发规范和约束。

所以可以简单理解：

Prompt
    ↓
我要做什么

Context
    ↓
我现在在哪里、有什么环境

七、Goal：明确任务目标

Agent 最怕的一件事情就是：

不知道任务到底要做到什么程度。

比如：

帮我优化一下登录页面。

“优化”其实非常模糊。

可以改成：

目标：

优化登录页面首屏加载性能。

要求：

1. 减少不必要的网络请求
2. 避免重复请求
3. 不改变现有业务逻辑
4. 优化完成后进行性能验证

这样 Agent 才知道：

目标是什么
+
哪些事情不能改变
+
最终要达到什么结果

八、Rules：告诉 Agent 什么可以做，什么不能做

Rules 主要解决：

Agent 执行过程中应该遵守什么规则？

例如：

规则：

1. 优先复用已有组件
2. 修改代码前先读取相关文件
3. 不要修改与当前任务无关的代码
4. 不要引入不必要的依赖
5. 不确定时先检查代码，不要直接猜测

这里面有一个非常重要的思想：

不要让 Agent 猜能够通过工具获取的信息。

例如：

项目里面明明已经存在：

src/components/Button.tsx

但是 Agent 不检查项目，直接创建：

src/components/LoginButton.tsx

虽然代码可能可以运行，但是从工程角度来看并不好。

所以可以告诉 Agent：

创建新组件之前，
必须先搜索项目中是否存在功能相同或相似的组件。

这实际上就是在通过 Prompt 约束 Agent 的行为。

九、Workflow：告诉 Agent 应该怎么做

这是 Agent Prompt 和普通 Prompt 非常明显的区别。

普通 Prompt：

帮我开发登录功能。

Agent Prompt：

请按照以下流程执行：

1. 分析项目结构
2. 查找登录相关代码
3. 分析现有实现
4. 制定修改方案
5. 修改代码
6. 运行 TypeScript 检查
7. 如果出现错误，定位并修复
8. 再次执行验证
9. 总结最终结果

这时候 Prompt 已经不只是一个需求描述。

它开始变成：

一个简单的 Agent 工作流程。

可以把它理解成：

分析
 ↓
计划
 ↓
执行
 ↓
验证
 ↓
修复
 ↓
再次验证
 ↓
完成

十、Tool：告诉 Agent 如何使用工具

Agent 和普通 LLM 最大的区别之一，就是 Agent 可以调用工具。

例如：

Agent
 ├── Search
 ├── Read File
 ├── Write File
 ├── Bash
 ├── Git
 └── MCP

例如一个代码 Agent 可以：

Search
 ↓
查找代码

Read
 ↓
读取文件

Write
 ↓
修改文件

Bash
 ↓
运行测试

MCP
 ↓
调用外部系统

所以 Prompt 中也可以定义一些工具使用规则。

例如：

工具使用规则：

1. 查找代码时优先使用搜索工具
2. 修改代码前必须先读取相关文件
3. 修改完成后运行相关检查
4. 不要为了验证简单问题执行整个项目构建

这样就可以减少 Agent 的一些无效操作。

十一、Validation：怎么判断 Agent 做对了？

这是 Agent Prompt 中非常重要的一部分。

因为：

代码生成出来
≠
代码正确

例如：

Agent 修改代码
      ↓
代码能编译吗？
      ↓
TypeScript 是否报错？
      ↓
ESLint 是否报错？
      ↓
功能是否符合需求？

所以可以告诉 Agent：

完成任务后必须执行：

1. TypeScript 检查
2. ESLint 检查
3. 必要时执行测试
4. 确认功能符合需求

于是 Agent 的工作流程就变成：

执行
 ↓
验证
 ↓
是否通过？
 ├── 否 → 分析问题 → 修复
 │              ↓
 │            再验证
 │
 └── 是 → 完成

这其实已经形成了一个基本的 Agent Loop。

十二、一个完整的 Agent Prompt

把前面的内容组合起来，可以得到一个比较完整的 Prompt：

# Role

你是一名资深前端开发工程师。

# Context

当前项目技术栈：

- React
- TypeScript
- Vite

开发原则：

- 优先复用现有代码
- 保持项目现有代码风格
- 尽量减少无关修改

# Goal

完成用户提出的前端开发任务。

# Rules

1. 执行任务前先分析项目结构。
2. 修改代码前先读取相关文件。
3. 优先搜索和复用已有组件。
4. 不确定时先检查代码，不要猜测。
5. 不要修改与任务无关的代码。
6. 不要引入不必要的依赖。

# Workflow

1. 理解用户需求。
2. 分析项目结构。
3. 查找相关代码。
4. 制定实现方案。
5. 执行代码修改。
6. 运行 TypeScript 检查。
7. 如果出现错误，定位并修复。
8. 再次执行验证。
9. 确认任务完成。

# Validation

任务完成必须满足：

- TypeScript 检查通过
- ESLint 检查通过
- 功能符合用户需求
- 没有明显的运行时错误

# Output

任务完成后输出：

1. 修改了哪些文件
2. 做了什么修改
3. 验证结果
4. 如果存在未解决的问题，明确说明

可以看到，这时候 Prompt 已经不太像我们平时理解的：

“一句提示词”。

而更像：

一套 Agent 的工作说明书。

十三、Agent Prompt 的核心：不是“写得漂亮”，而是“控制行为”

很多人刚开始学习 Prompt Engineering 时，会把重点放在：

怎么写出一句更好的 Prompt？

但是到了 Agent 场景，关注点会发生变化。

从：

怎么让 AI 回答得更好？

变成：

怎么让 Agent 稳定地完成任务？

这是一个非常重要的变化。

例如：

简单 Prompt

帮我生成一个页面。

Agent Workflow

读取需求
 ↓
分析设计稿
 ↓
识别页面结构
 ↓
查找已有组件
 ↓
选择组件
 ↓
生成页面
 ↓
运行检查
 ↓
视觉验证
 ↓
发现问题
 ↓
修改
 ↓
再次验证

这时候我们关注的已经不是：

Prompt 写得够不够“聪明”。

而是：

Agent 的整个执行过程是否稳定。

十四、Prompt 和 Skill 有什么区别？

在 Agent 开发中，经常还会遇到一个概念：

Skill。

可以简单理解：

Prompt
=
一次任务

Skill
=
一套可复用的能力

例如：

Prompt：

帮我生成一个登录页面。

这是一次任务。

而一个：

页面生成 Skill

可能定义：

触发条件：
用户要求生成页面

输入：
页面需求 + 设计稿

执行流程：
1. 分析设计稿
2. 查找组件
3. 生成页面
4. 运行检查
5. 进行视觉验证

输出：
页面代码 + 验证结果

所以可以简单理解：

Prompt
 ↓
这次我要做什么

Skill
 ↓
这一类任务应该怎么做

这也是 Agent 工程从简单 Prompt 开始，逐渐走向 Workflow、Skill、Tool Calling 的一个过程。

十五、Agent Prompt 怎么调试？

实际开发 Agent 时，很少能够一次把 Prompt 写好。

通常需要：

执行
 ↓
观察
 ↓
发现问题
 ↓
分析原因
 ↓
修改 Prompt / Skill
 ↓
重新执行
 ↓
继续观察

例如：

Agent 经常重复创建组件。

不要简单认为：

“AI 太笨了。”

可以继续分析：

① 是否正确理解了任务？
        ↓
② 是否找到了正确的 Skill？
        ↓
③ 是否读取了项目中的组件？
        ↓
④ Prompt 是否规定了组件复用？
        ↓
⑤ Workflow 是否要求先搜索？
        ↓
⑥ 是否有验证步骤？

如果发现：

Agent 根本没有搜索已有组件。

那么可以增加规则：

创建新组件之前，
必须先搜索项目中是否存在功能相同或相似的组件。

然后重新执行。

如果问题解决了，说明 Prompt 的约束起作用了。

十六、我理解的 Agent Prompt 调试流程

在实际开发过程中，我比较推荐按照下面的顺序排查：

用户输入
   ↓
① 意图理解
   ↓
② Skill 匹配
   ↓
③ Workflow 执行
   ↓
④ Tool Calling
   ↓
⑤ 执行结果
   ↓
⑥ Validation
   ↓
⑦ 最终结果

如果出现问题，就定位问题发生在哪一层。

例如：

用户明明要求修改 Button
Agent 却修改了 Dialog

可能是：

意图理解错误

如果：

Agent 找到了 Button
但是没有按照规定修改

可能是：

Workflow / Rules 有问题

如果：

Agent 修改正确
但是执行测试时报错

可能是：

代码执行 / Tool 调用问题

所以：

Agent 调试，本质上也是在调试它的“执行流程”。

十七、Agent Prompt 的几个核心原则

最后总结一下。

1. 目标明确

不要：

帮我优化一下。

尽量：

优化登录页面首屏加载性能，
减少不必要的网络请求，
并保证现有业务逻辑不发生变化。

2. 上下文充分

告诉 Agent：

技术栈
项目结构
业务背景
代码规范
已有能力

减少 Agent 自己猜测的空间。

3. 规则明确

明确：

应该做什么
不要做什么
什么时候可以执行
什么时候必须停止

4. 流程清晰

复杂任务不要只给最终目标。

可以拆成：

分析
→ 计划
→ 执行
→ 验证
→ 修复
→ 再验证

5. 必须验证

不要认为：

生成完成
=
任务完成

而应该：

生成
 ↓
验证
 ↓
修复
 ↓
再次验证
 ↓
完成

6. 尽量不要让 Agent 猜

如果某个信息可以通过工具获得：

组件在哪里？
接口是什么？
项目结构是什么？
配置是什么？

就让 Agent：

Search
 ↓
Read
 ↓
Analyze
 ↓
Execute

而不是：

凭经验猜
 ↓
直接执行

十八、总结

如果只用一句话来解释：

Agent Prompt Engineering，就是通过 Prompt 设计，让 Agent 更准确地理解任务，并按照预期的方式完成任务。

普通 Prompt 更关注：

让 AI 回答正确

Agent Prompt 更关注：

让 Agent 执行正确

可以用一个简单的公式理解：

Agent Prompt
=
Role
+
Context
+
Goal
+
Rules
+
Workflow
+
Tools
+
Validation

而当我们继续往下学习 Agent，就会逐渐接触：

Prompt
   ↓
Skill
   ↓
Tool Calling
   ↓
Workflow
   ↓
Memory
   ↓
Context Engineering
   ↓
Validation
   ↓
Retry / Fallback
   ↓
Agent

所以我认为，学习 Agent Prompt 工程最重要的并不是研究：

“怎样写一句特别牛的 Prompt？”

而是开始思考：

“我怎样通过 Prompt、Skill、Tool 和 Workflow，让 Agent 稳定地把一件事情做完？”

当思考方式从“让 AI 回答问题”转变成“让 Agent 完成任务”，也就真正开始进入 Agent 工程了。

参考关键词

如果继续深入学习 Agent，可以进一步了解：

  • Prompt Engineering
  • Context Engineering
  • Agent
  • Agent Workflow
  • Skill
  • Tool Calling
  • MCP
  • ReAct
  • Plan-and-Execute
  • Reflection
  • Harness
  • Output Validation
  • Retry / Fallback
posted @ 2026-09-17 18:16  嘿！那个姑娘  阅读(4)  评论(0)    收藏  举报