Agent 使用技巧分享：从 Prompt 到 Agent OS 的实践路线

很多人开始使用 Agent 后，最先感受到的往往不是惊喜，而是一种不稳定。

它有时像一个反应极快的同事：能读代码、会查资料、能改文件，也愿意跑测试。可一旦任务变长、边界变多，或者需要真的碰到部署、数据和外部系统，它又很容易回到“看起来都懂，结果没有交付”的状态。

我想把这个栏目写给正在经历这种落差的人。

这里不收集“让模型变聪明”的神奇咒语，也不把多开几个 Agent 当作进步。这个栏目更关心另一件事：怎样把 AI 放进一个能完成真实工作、能留下证据、失败后能恢复的工程闭环。

这个专题会解决什么问题

一套可靠的 Agent 协作方式，通常不只是一段 Prompt。它至少还需要：

目标与验收
→ 合适的上下文
→ 可复用的工作方法
→ 边界清晰的工具
→ 能验证、能恢复的执行环境
→ 把失败留下来的评测集

模型会换，客户端会换，流行术语也会换。真正值得持续积累的，是这套围绕真实任务形成的工作资产。

阅读顺序

这个专题的文章可以独立阅读；如果你刚开始系统使用 Agent，建议按下面顺序进入：

  1. Prompt Engineering：如何给 Agent 定义可执行任务：先学会把“帮我做一下”变成能验收的任务契约。
  2. Context Engineering：为什么 Agent 会越聊越笨：理解上下文、项目状态和长期任务交接。
  3. Skill 设计：如何把 Prompt 升级成可复用工作流：把反复解释的经验变成可版本化的方法包。
  4. Harness Engineering：如何构建可验证的 Agent 执行闭环：让 Agent 不只会行动，也会验证、恢复和停止。
  5. AGENTS.md 实战：如何让 Agent 读懂代码仓库：给新 Agent 一个高信噪比的项目入口。
  6. Tool Engineering：如何设计 Agent 能稳定调用的工具：减少工具误选、超大返回和不透明副作用。
  7. Multi-Agent 实战：什么时候该拆分，什么时候不该：只在拆分带来真实收益时增加并行度。
  8. Agent Evals：如何用评测集持续优化 AI 工作流：把一次次失败变成以后不会再踩的回归用例。
  9. 个人 Agent OS：如何把 Skills、Tools 与 Evals 组织起来：把前面的资产收束成可跨项目复用的个人系统。

每篇文章的写法

每篇文章都会尽量回答五件事：

  1. 它要解决的真实问题是什么；
  2. 常见但无效的做法为什么会失败；
  3. 推荐做法的边界是什么；
  4. 一个可以照着改的完整例子；
  5. 如何检查自己是否真的做对了。

因此，文中的模板、命令和目录结构都不是为了凑“干货”。它们应该能被读者复制到自己的项目中，再根据项目规模、权限边界和风险进行删改。

我也会保留一个原则：能让脚本验证的事情，不靠 Agent 口头保证；需要人的价值判断，不伪装成自动化。

从哪一篇开始

如果你现在仍然主要靠聊天框和长 Prompt 协作，请先读第一篇。它会把最常见的模糊请求，改写成一个 Agent 可以自主推进、也可以让你检查结果的任务闭环。

如果你已经在做多轮任务、自动化或项目级协作，可以直接从上下文、Skill 或 Harness 相关篇章进入。

AI 实现摘要

  • 要解决的问题：为 Agent 工程实践提供按主题组织、可独立阅读的系列入口。
  • 适用版本与前置条件：适用于能够读取 Markdown、执行工具或协作代码项目的 AI Agent；具体产品能力以各自官方文档为准。
  • 输入、输出与验收标准：输入是一个真实任务；输出应包含明确目标、可复用方法、验证证据与风险边界。读者应能找到与自己阶段匹配的下一篇文章。
  • 文件改动清单：本篇为专题导读，不要求改动读者项目文件。
  • 完整命令：无。
  • 测试步骤与预期结果：根据“阅读顺序”选择一篇文章后，应能得到至少一项可在自己项目实践的动作。
  • 常见错误、回滚方法与安全边界：不要把专题中的模板不加判断地用于生产环境；涉及删除、外部写入、付费和敏感数据时，必须保留人工审批边界。