AI Agent 使用技巧——从入门到入土

一、大模型是如何工作的

1. Token

大模型处理内容时，并不能按照“字”或“单词”理解内容，而是先将文本拆分成一个个小单位，也就是 Token。

模型输入和输出的长度通常都使用 Token 计算，因此 Token 直接关系到两个问题：

• 一次能够输入多少内容；
• 模型能够生成多少内容。

2. 上下文窗口

每向模型发送一条新的提示词，或是 Agent 运行一条命令/调用一个工具拿到一个结果，实际上不只是单独将新内容发给模型，而是是将这些东西全部一块打包给模型：

• 系统提示词；
• 用户提示词；
• 当前聊天中的历史消息；
• 上传的文档、图片等；
• Agent 获取的工具结果；
• 产品自动加入的记忆或项目资料；
• 工具、技能、连接器列表。

模型能够一次处理的上下文总量存在上限，这就是“上下文窗口”。

主流模型的上下文窗口基本都达到了 1 M Token，但这不意味着模型真的能“记住”这么多信息。

3. 注意力

Transformer 大模型的重要基础之一是注意力机制。

模型会根据当前任务，在上下文中寻找彼此相关的信息，并决定哪些内容更加重要。换句话说，当你真的在一个对话内塞了大量的信息，大模型实际上会忽略其中的很多内容。

这也解释了一些常见现象：

• 重要要求埋在很长的文字中，模型可能忽略；
• 一个聊天包含大量无关内容，会增加干扰；
• 明确的标题、列表和结构通常比杂乱的自然语言更容易处理；
• 长任务中，明确记录当前状态往往比完全依赖聊天历史更加可靠。

因此，AI 使用中的很多技巧，本质上都可以理解为一件事：让模型更容易找到真正重要的信息。

二、Agent 是如何工作的

传统聊天模型主要负责“回答问题”，而 Agent 则可以进一步执行任务。

Agent ＝ Model + Harness

其中，Model 是负责理解、推理和生成内容的大模型；Harness 则是围绕模型构建的一整套执行环境。

Harness 可能负责：

• 系统提示词；
• 文件读写；
• 命令行操作；
• 浏览器访问；
• MCP 工具调用；
• 搜索互联网；
• 运行代码；
• 管理上下文；
• 多步骤任务执行；
• 检查任务是否完成。

例如，一个 Coding Agent 接到“修复这个 Bug”的任务后，可能执行：

1. 阅读项目文档；
2. 搜索相关代码；
3. 分析问题原因；
4. 修改代码；
5. 运行测试；
6. 根据报错继续修改；
7. 最后汇报结果。

大模型本身不会直接操作电脑。真正负责执行这些操作的是 Agent 提供的工具和运行环境。

这也是为什么：相同的模型，在不同 Agent 产品中的表现可能明显不同。

模型决定了推理能力的上限，而 Harness 决定了模型能够获取什么信息、调用什么工具，以及如何完成任务。

三、如何让 AI 给出令人满意的结果

1. 通用原则

1.1 选择合适的模型

对于简单任务，例如：

• 翻译一句话；
• 修改语法；
• 提取信息；
• 简单格式转换；
• 步骤明确的执行环节；

快速模型通常已经足够。（不差钱另说）

但对于：

• 软件工程；
• 长文档分析；
• 多条件决策；
• 复杂推理；
• 多步骤 Agent 任务；

更强的模型通常更可靠。

失败是成功之母，充钱是成功支付

即使你的意思表达没那么清楚，推理能力更强大的模型还是有可能把你的意思猜透、把问题摸清，依靠力大砖飞的参数量、电表倒转的算力和精妙绝伦的算法，给出更好的结果。

1.2 给 AI 充足的信息

AI 是通过已有得信息推测出结果，所以最好将任务所需的背景信息、约束限制、参考来源等尽可能准备全面。

对于复杂任务，往往难以在一开始就将全部需求组织完整，此时可以使用类似 /grill-me 的 Skill，或是在提示词中加上一句“任何不确定的地方与我确认”，如此有助于与 Agent 对齐颗粒度。

2. Prompt Engineering：把人话说清楚

对于现今的前沿模型、对于多数任务而言，只要 把需求说清楚 ，它通常就可以自行完成任务。

具体来说，包括：

• 要做什么。
• 怎样算完成。
• 遇到什么要停下来问你。

2.1 使用 Markdown 组织信息

Markdown 是 AI 时代的通行语言，几乎所有 AI 输出的回复格式都是 Markdown。
常用结构包括：

# 任务

## 背景

## 当前情况

## 要求

1. 要求一
2. 要求二

善用 Markdown 可以让模型更好地理清提示词的结构。

点击跳转到更多常用 Markdown 语法

2.2 善用系统提示词和长期规则

如果某些要求会反复使用，就没有必要每次重新输入。

例如：

• 给我用中文回复！！！
• 不要问我，我看不懂，你自己看着弄吧。
• 请把我当成傻子，再给我解释一遍。

这些长期规则更适合放入：

• 系统提示词；
• 自定义指令；
• 项目文档；
• AGENTS.md；
• Agent 的长期配置。

这样可以把当前提示词保持得更加简洁。更重要的是，系统提示词和单独设定的自定义指令等往往具有更高的优先级，在长对话中 AI 也更不容易忘记这些约定。

3. Context Engineering：管理 AI 知道什么

Prompt Engineering 关注的是：这一轮应该告诉 AI 什么。

Context Engineering 更关注：模型在处理这个任务时，应该知道哪些信息。

上下文容量是一种宝贵的资源。对于复杂任务，怎么在合适的时机，给大模型提供合适的信息，而不是一股脑将全部信息塞进去，这通常比单纯研究提示词更加重要。

3.1 一个聊天保持一个主要目标

一个聊天最好围绕一个持续目标，避免在一个聊天中混杂数个互不相干的话题。

3.2 长任务中避免上下文污染

任务进行得越久，聊天历史通常越复杂。

里面可能同时存在：

• 已经被推翻的方案；
• 旧版本代码；
• 错误假设；
• 临时讨论；
• 已经完成的任务。

如果所有信息都依赖聊天历史保存，模型有时会难以判断什么才是当前事实。

因此，长期任务最好维护明确的“当前状态”文档，这样比让模型从几百条聊天记录中重新推断更加可靠。

3.3 避免在一个会话中切换模型

在同一会话中切换不同模型，容易破坏对话连贯性、引发上下文理解偏差并导致缓存失效进而增加成本。中途调整 effort（思考强度）一般没关系。

4. Harness Engineering：Agent First

Humans steer. Agents execute.

—— OpenAI

如果 Prompt Engineering 是“怎么提问”，Context Engineering 是“给它什么信息”，那么 Harness Engineering 更关注：如何给 Agent 搭好环境，让 Agent 能够持续、稳定、高效地工作。

Skill（技能）

Skill 是一组预先写好的指令、脚本和参考资料，打包成一个文件夹，用来教 Agent 如何以固定、可靠的方式完成某一类任务。

当同一类任务反复在做，而且每次都要重新交代一遍背景和要求，此时就适合创建 Skill。

主流 Agent 产品大多都内置了类似 Skill-creator 的 Skill，使用自然语言就能轻松创建 Skill。

MCP（连接器）

对于一般用户而言，可以不严谨地把 MCP 当作函数理解：Agent 向 MCP 发送请求，MCP 执行操作、返回信息。它让 Agent 有了连接外部工具和数据的能力。

至于 Plugin、Costomization、插件 等功能，实际上是 Skill 和 MCP 的组合。

四、Vibe Coding（许愿式编程）

让 Agent 管理一个长期项目，最容易出现的问题之一，是前几次修改效果很好，但项目越来越大以后，Agent 开始：

• 忘记项目规则；
• 重复已有实现；
• 修改不该修改的文件；
• 不知道项目当前进度。

解决这些问题，不能只靠更长的 Prompt。

1. 建立成熟的项目文档体系

项目文档应该让 Agent 能够快速回答几个问题：

• 这个项目是做什么的？
• 当前架构是什么？
• 有哪些重要规则？
• 当前正在开发什么？
• 哪些任务已经完成？
• 还有哪些已知问题？

而不是每次都要阅读整个仓库寻找答案，或依赖用户每个对话开始时都写一遍约束。

1.1 渐进式披露

可以建立类似这样的结构：

AGENTS.md
docs/
├── architecture.md
├── status.md
├── rules.md
├── plans/
├── evidence/
└── archive/

其中 AGENTS.md 只作为入口和地图，不应该无限膨胀成整个项目的知识库。

详细事实放入对应文档，并尽量保证每类重要信息都有唯一的事实来源。

1.2 当前状态和历史记录分开

Agent 最容易混淆的是：“现在是什么状态”和：“以前发生过什么”。

因此正式项目文档最好只描述当前有效事实。历史方案、旧计划、维护记录等信息则单独归档。

这样 Agent 打开项目时，不需要自己判断某段文字究竟还是当前规则，还是之前已经废弃的方案。

1.3 让 Agent 有证据地完成任务

对于重要任务，可以要求 Agent 在完成以后说明：

• 修改了什么；
• 为什么修改；
• 运行了哪些测试；
• 测试结果是什么；
• 是否还有已知风险。

对于长期项目，还可以保存必要的证据，例如测试结果、性能数据和故障分析记录。

这样以后重新分析问题时，可以直接找到当时结论的依据，而不是依赖聊天记录，或重跑测试。

1.4 让 Agent 主动更新文档

如果 Agent 只顾代码修改而不一并更新文档，那么项目文档很快就会被大量的过时、错误信息填满，进而影响 Agent 接下来的工作。

可以在 AGENTS.md、规则文档中添加“每次任务结束都评估文档影响”的要求，或新建一个 Skill 专门用于 Agent 在任务结束后按流程检查并更新文档。

对于执行中任务，也可以保存一份进度文档，便于跨会话交接，也能避免压缩上下文后模型遗忘当前状态。

另外，还可以不定时发起一次全仓的文档、代码审查，有助于发现一些隐藏问题，并防止文档长期漂移。

2. 使用机械化检查

能用工具自动验证的事情，尽量不要只依赖 Agent 的自觉。

例如：CI/CD、格式检查等。

五、Vibe Working

演示文稿

AI 做 PPT，其效果基本取决于用户的想象力、提示词水平，以及模型的审美、Harness 的能力。

另外，如果某款 Agent 产品只能做出“无法二次编辑的扁平图片式 PPT”，那么这个项目可能有帮助：PPT-Master ，它实际上是一份 Skill。

六、Personal Agent

探索中……