The essential skill of the agent era is managing AI, not just using it

过去一年，很多人都在讨论如何更好地使用 AI，尤其是如何使用 Agent。但我越来越觉得，真正的问题可能不是“怎么写出一个更好的提示词”，而是：我们到底有没有能力管理一个外部智能系统。

如果只把 Agent 当成一个问答工具，那么使用方式就会非常简单：我问，它答；我提要求，它生成内容；我不满意，再让它重写。但一旦任务变复杂，比如让它帮你做调研、写方案、改代码、设计产品、规划项目、整理知识库、持续追踪一个方向，事情就不再是“提问质量”的问题，而变成了“管理能力”的问题。

换句话说，Agent 时代真正重要的能力，不只是使用 AI，而是管理 AI。

这件事其实并不陌生。人类过去几十年已经发展出很多成熟的方法，用来管理自己的注意力、任务、项目和知识。时间管理、项目管理、知识管理，表面上看是旧时代的方法，但它们背后的底层逻辑，在 Agent 时代并没有过时。它们只是需要被重新翻译。

过去，我们管理自己，是因为人的注意力有限、时间有限、记忆有限、执行力有限。现在，我们管理 Agent，是因为 Agent 的上下文有限、目标理解有限、判断边界有限、长期记忆有限。问题的对象变了，但管理的本质没有变：如何让一个复杂系统在有限资源下，持续朝正确方向行动。

所以我觉得，管理 Agent 的能力，本质上可以理解成一种新的综合能力：智能体运营能力。 它不是单纯的提示词技巧，也不是简单的自动化流程搭建，而是把人的目标、知识、判断、流程和外部智能组织起来，让它们形成一个稳定、可复用、可校准的协作系统。

时间管理给我们的启发，是如何管理 Agent 的注意力预算。人做时间管理时，会区分深度工作、浅层任务、例行事务和临时打断。管理 Agent 也一样。不是所有任务都应该用同一种方式交给它。有些任务可以快速委托，比如改写一段文字、整理会议纪要、生成几个标题；有些任务需要分阶段推进，比如写一篇深度文章、做一个产品方案、调研一个创业方向；还有些任务必须设置检查点，比如涉及重大决策、复杂判断、真实数据、代码修改和商业策略的任务。

这里有一个关键差异：人的时间管理，核心是在对抗分心和拖延；Agent 的时间管理，核心是在对抗上下文丢失和方向漂移。 人会累，会不想做，会被其他事情打断；Agent 不会真正疲惫，但它会误解你的目标，会把不确定的地方自动补全，会在错误方向上高速执行。人类时间管理里的“优先级”“任务边界”“下一步行动”，迁移到 Agent 管理里，就变成了“上下文预算”“任务澄清”“检查点设计”。

项目管理给我们的启发，是如何管理 Agent 的委托与验收。很多人用 Agent 效果不好，不是因为 Agent 能力差，而是因为委托方式太粗糙。比如“帮我调研一下 AI Agent 方向”“帮我写一篇文章”“帮我做一个产品方案”，这些指令看起来明确，其实都非常含糊。它们没有说明真正要解决什么问题，没有说明输出给谁看，没有说明质量标准，也没有说明什么情况需要停止确认。

在人类项目管理里，一个成熟的管理者不会只说“你去做一下这个项目”，而会定义目标、范围、里程碑、风险、依赖和验收标准。管理 Agent 也应该这样。Agent 不是只需要任务，它还需要 Definition of Done，也就是“什么叫做完”。 如果你不定义完成标准，Agent 就会用自己的默认模式交付一个“看起来完整”的东西，但这个东西未必真的能用。

知识管理给我们的启发，是如何管理 Agent 的上下文和记忆。人类做知识管理，不是为了收集更多信息，而是为了在正确场景下调用正确知识。Agent 也是一样。很多人以为只要把更多资料喂给 Agent，结果就会更好，但这并不一定成立。上下文越多，反而越容易混乱；历史信息越多，反而越可能污染当前判断。

真正有效的知识管理，不是信息堆积，而是结构化调用。你需要区分哪些是长期稳定偏好，哪些是当前项目背景，哪些是临时任务材料，哪些是已经过期的旧判断。否则 Agent 会越来越像一个被历史材料淹没的系统，它看似知道很多，却不知道此刻什么最重要。

因此，管理 Agent 的核心不是“让它知道一切”，而是让它在当前任务中知道该知道的东西。

如果把这三类方法合在一起看，会发现一个很清晰的结构：时间管理帮助我们管理任务入口，项目管理帮助我们管理执行过程，知识管理帮助我们管理上下文资产。三者合起来，才构成真正的 Agent 管理能力。

第一个最实用的方法，是把 GTD 改造成 Agent 的任务收件箱。GTD 的思想很简单：不要让任务以混乱念头的形式停留在脑子里，而是先收集，再澄清，再组织，再执行，再回顾。迁移到 Agent 管理里，就是不要把一个模糊想法直接丢给 Agent，而是先把它整理成一个可执行对象。

可以给自己准备一个固定的任务入口模板：

任务名称：
我真正想解决的问题：
背景信息：
期望输出：
使用场景：
完成标准：
不希望出现什么：
需要先问我的问题：

比如你不是简单地说“帮我调研一下 AI Agent 创业方向”，而是这样委托：

任务名称：调研 AI Agent 创业方向

我真正想解决的问题：
判断未来 3-6 个月，哪些 Agent 产品方向值得重点关注。

背景信息：
我关注产品经理视角、工具调用、知识工作、个人 OS、工作流自动化，也关注其中可能出现的创业机会。

期望输出：
给出 5 个值得关注的方向，每个方向包括代表公司、用户痛点、商业模式、机会判断和主要风险。

使用场景：
用于公众号选题、个人研究和未来创业方向判断。

完成标准：
不是新闻摘要，要有判断、有反共识、有风险识别；需要区分事实、推测和个人判断。

不希望出现什么：
不要泛泛讲趋势，不要只列大公司，不要堆概念。

需要先问我的问题：
如果 B 端和 C 端会影响分析结论，先问我更关注哪一类。

这个方法看似简单，但非常重要。它解决的是 Agent 协作里的第一道关口：先把任务从灵感、情绪和念头，转化成一个可以被执行、被检查、被复用的对象。

第二个方法，是为不同任务建立 Definition of Done。很多时候，Agent 不是没有完成任务，而是完成了一个你并不真正认可的任务。它写完了文章，但文章没有主线；它做完了调研，但只是资料拼贴；它改完了代码，但没有说明验证方式；它做完了方案，但没有指出关键风险。

所以你需要提前定义“什么叫高质量完成”。比如写文章时，可以给 Agent 这样的标准：

这篇文章必须满足：
有一个清晰的核心判断，而不是资料拼贴。
开头要提出真实问题，让读者愿意继续读。
中间要有递进关系，而不是并列罗列。
每一部分都要服务于主线。
结尾要把问题推进一层，而不是喊口号。
语言自然连贯，不要一句一段，不要过度金句化。

做调研时，可以换成另一套标准：

这份调研必须满足：
区分事实、判断和推测。
标明关键不确定性。
给出至少 3 个反直觉发现。
不只总结别人说了什么，还要判断为什么重要。
最后给出可行动建议。

做产品方案时，可以这样定义：

这个方案必须满足：
先定义用户和场景，再定义功能。
先讲核心路径，不要一上来铺满所有模块。
每个功能都要对应明确用户问题。
必须说明 MVP 范围、非 MVP 范围和后续演进方向。
必须指出至少 3 个失败风险。

这背后的原则是：不要只告诉 Agent 做什么，还要告诉它什么叫做得好。 人类管理里，很多返工都来自验收标准不清楚；Agent 协作也是一样。你越早定义质量边界，后面越少陷入“重写一版”“再优化一下”“还是不对”的循环。

第三个方法，是用里程碑检查点替代一次性大委托。复杂任务最怕一次性委托到底。因为 Agent 很擅长连续生成，它会顺着一个方向一直往前走，但如果第一步理解偏了，后面所有内容都会在错误基础上越堆越厚。

更好的方式，是把复杂任务拆成阶段，并明确要求它在关键节点停下来。比如你要让 Agent 帮你做一个产品 PRD，不要一开始就说“写一份完整 PRD”，而是让它按阶段推进：

第一步：先澄清问题，列出这个产品到底解决什么用户痛点，不要写方案。
第二步：基于问题，提出 3 种可能的产品路径，并比较优缺点。
第三步：选定一个方向后，再拆 MVP 功能。
第四步：把 MVP 功能转成用户流程。
第五步：最后再写 PRD。
每完成一步先停下来，等我确认后再继续。

这套方法的本质，是把人类项目管理里的阶段评审迁移到 Agent 协作里。Agent 的速度越快，越需要检查点。 因为速度本身不是优势，方向正确的速度才是优势。没有检查点的高速执行，很容易变成高速偏航。

第四个方法，是为长期任务准备 Context Pack，也就是上下文包。很多人每次使用 Agent 都像第一次见面：重新介绍自己、重新解释项目、重新说明偏好、重新强调不要犯什么错误。这其实非常浪费。更好的方式，是为高频任务沉淀固定上下文。

比如公众号写作可以有一个上下文包：

我的写作偏好：
自然连贯，有思想递进，不要一句一段，不要过度金句化。

我常讨论的主题：
AI、Agent、知识管理、个人成长、生命力、长期主义、产品设计、复杂系统。

我的读者画像：
对技术和个人成长感兴趣，有一定认知基础，但不喜欢空泛概念。

我不喜欢的表达：
套话、口号、过度煽情、碎片化排版、为了显得深刻而故弄玄虚。

我希望文章达到的效果：
不是提供标准答案，而是帮助读者换一个更深的视角理解问题。

产品研究也可以有一个上下文包：

我关注的主线：
AI Agent、工具调用、知识工作、工作流自动化、个人 OS、AI 原生产品。

我判断机会的标准：
是否解决真实高频问题，是否能形成工作流入口，是否有持续数据积累，是否能从工具走向系统。

我不关注的方向：
只有概念包装、缺少使用场景、依赖短期流量、没有产品复用价值的方向。

我常用的分析角度：
用户痛点、任务频率、替代成本、商业模式、数据闭环、分发路径、组织阻力。

上下文包的价值在于，它让 Agent 不再是一个泛泛聪明的外部工具，而是更接近一个理解你长期项目的协作者。但也要注意，上下文包不是越大越好，而是越准确越好。 它应该像一份高质量项目 brief，而不是一个信息垃圾桶。

第五个方法，是建立不同类型 Agent 的“岗位说明书”。在人类组织里，一个人不会同时被当成战略顾问、执行助理、审稿人、数据分析师和项目经理。Agent 也一样。如果你每次都让它扮演一个万能助手，它就很容易输出一种泛化的平均答案。

更好的做法，是为不同任务设置不同角色，并明确它们的职责边界。比如：

研究员 Agent：
负责搜集资料、交叉验证、提炼变量，不急着下结论。

产品经理 Agent：
负责定义用户、场景、流程、MVP、指标和风险。

编辑 Agent：
负责文章结构、语气、节奏、标题和读者感受。

审稿人 Agent：
专门挑问题，指出逻辑断裂、证据不足和表达冗余。

项目经理 Agent：
负责拆任务、排优先级、识别依赖、追踪风险和定义验收标准。

关键不是给 Agent 起角色名，而是明确“它现在只做什么”。比如你可以这样说：

你现在只扮演审稿人，不要重写全文。请从逻辑、结构、证据、表达四个角度指出这篇文章的问题，并按严重程度排序。

或者：

你现在只扮演项目经理，不要发散创意。请把这个目标拆成两周内可执行的任务列表，并标注依赖、风险和验收标准。

这种方式会显著提升输出稳定性。因为你不是在调用一个模糊的“聪明助手”，而是在调用一个职责清晰的认知岗位。角色越清楚，输出越可控；边界越明确，协作越稳定。

第六个方法，是把复盘机制用在你和 Agent 的协作方式上。每次任务结束后，不要只评价这次结果好不好，而要追问：这次协作为什么好，为什么不好，下一次能不能把经验沉淀下来。

可以用三个问题做复盘：

这次任务哪里交代清楚了？
哪里因为上下文不足或标准不清导致偏差？
下次可以把哪条规则沉淀进模板？

比如你发现 Agent 写文章总是太碎，就不要每次临时提醒“不要一句一段”，而是把它沉淀进写作上下文包。你发现 Agent 做调研总是停留在资料层，就把规则改成：“每一部分都必须区分事实是什么、这意味着什么、我可以怎么利用它。”你发现 Agent 做产品设计总是平铺功能，就把规则沉淀成：“优先呈现核心路径，不要把所有能力同时放在首页；每个界面只能服务一个主要动作。”

这件事很关键。因为真正的进步不是让某一次回答变好，而是让下一次协作的起点变高。不要只优化结果，要优化协作系统本身。

如果把这些方法总结起来，会发现管理 Agent 其实可以形成一套完整流程：先用任务收件箱澄清需求，再用 Definition of Done 定义质量标准，然后用里程碑检查点控制过程，用上下文包提供背景，用角色说明书明确职责，最后通过复盘机制持续优化协作协议。

这套流程并不复杂，但它会把你和 Agent 的关系从“临时问答”推进到“长期协作”。你不再是每次从零开始发出指令，而是在逐渐搭建一套属于自己的智能协作系统。

我认为这会是未来很重要的分水岭。大多数人会停留在“会用 AI”，也就是知道怎么提问、怎么让它改写、怎么让它生成内容。但更少数的人会进入“会管理 Agent”的阶段。他们知道如何定义任务，如何配置上下文，如何拆解项目，如何设置检查点，如何建立验收标准，如何沉淀长期记忆，如何让多个 Agent 分工协作。

这两者的差距，可能会越来越大。

因为 AI 的能力越强，人的差异就越不体现在“谁能让 AI 做一件小事”，而体现在谁能把 AI 组织成一个稳定的生产系统。这就像过去会使用工具的人很多，但真正能设计流程、组织团队、管理项目、沉淀知识的人，永远更稀缺。

所以，Agent 时代最值得训练的能力，不是把提示词写得更漂亮，而是把自己训练成一个更好的管理者。你要能管理目标，管理上下文，管理过程，管理质量，管理记忆，也管理你自己的判断边界。

最后，Agent 并不会自动让人变强。它只会放大人的系统能力。一个目标混乱的人，会用 Agent 生成更多混乱；一个判断模糊的人，会用 Agent 制造更多看似完整的幻觉；一个没有复盘习惯的人，会反复在同一个问题上返工。

但反过来，一个有清晰目标、结构化方法和持续复盘能力的人，会因为 Agent 获得前所未有的杠杆。因为他管理的不再只是自己的时间和注意力，而是一个可以搜索、生成、执行、比较、复盘、迭代的外部智能系统。

未来真正厉害的人，可能不是拥有最多 Agent 的人，而是最会管理 Agent 的人。 他们不是在和 AI 聊天，而是在设计一种新的工作方式；不是在追求一次性回答更聪明，而是在让整个协作系统越来越可靠。