AI Agent 一周赚1万美金：3个关键升级揭秘

一位海外博主分享了他用 AI Agent（智能体）在一周内为业务带来 1 万美元收入的完整方法论。有意思的是，让他成功的并非大多数人以为的路径——不是装更多技能、加更多工具、给更多记忆，而是恰恰相反。这套经验值得每一个在做 Agent 自动化的人认真研究。

为什么“加更多功能”反而让 Agent 越来越差

这位博主坦言，最初一个月他做的正是所有人都在做的事：安装更多技能、增加更多工具、扩充记忆容量。结果每一次升级，他的 Agent 都变得更慢、更臃肿，而他对它的信任反而下降。

他提出了一个核心洞察：Agent 的真正价值，不在于它尝试了多少工作，而在于其中有多少工作是你完全不需要检查的。他把 Agent 的运行拆成三个支柱——它做了多少工作、你有多信任它、有多少事情在你不参与的情况下自动完成。关键在于，这三个数字不是相加，而是相乘。

这意味着最小的那个数字决定一切。而通常最小的就是“信任度”。如果你只信任 Agent 一半的产出，那么把它的工作量翻倍，得到的不是一个员工，而是给自己制造了第二份工作——因为超过信任线的所有产出，最终都会回到你的办公桌上。

让 Agent “无法悄悄失败”的第一个升级

博主赚到这 1 万美元的工作流其实极其简单：一个读取收件箱、找出最佳商机、并自动回复的 Agent。这原本是他每天早上做的事，但因为放在最后、又累又困，他做得很糟。Agent 不比他聪明，只是永远不会累、永远不会漏掉任何一天。

但他第一次运行时就踩了坑：Agent 报告说它发了 9 封回复，实际上发了 0 封，而且没有任何报错。Agent “完成”了，宣布“搞定”，然后若无其事地继续。这暴露了当前 Agent 最危险的问题——它们常常分不清“真正做了某事”和“声称做了某事”的区别。

为此他总结了四条做法：

1. 在每个技能末尾加上验证指令

他现在写的每个技能都以同一句话结尾：“在告诉我这件事成功之前，打开你产出的东西，再检查一次是否符合我的要求。如果你打不开它，就说明你没做。报告你真正发现的，而不是你打算做的。”

这句话之所以有效，是因为 Agent 在无人监督时会以“意图”评判自己——它执行了步骤，所以认为成功了。而这句话强迫它转而以“实际产物”来评判自己。

2. 该写指令还是该写代码

他的规则是：如果一个步骤有很多种正确做法，就写指令让它自由发挥；但如果只有唯一一种正确做法，就让它写代码执行。因为模型不会“运行”你的指令，它只是阅读并每次都用不同方式即兴演绎。

他举了个真实的坑：同一个“YouTube 专属视频报价”问题，Agent 在三个不同对话里给出了 4000、6000、4500 美元等完全不同的数字。所以任何涉及数字的逻辑，现在都写进脚本，确保相同输入永远得到相同输出。额外的好处是脚本不会被载入上下文，因此更便宜也更可靠。

3. 前置条件检查

他的回复器依赖一些它无法控制的东西——收件箱连接、读取报价的文件等。如果缺失，Agent 不会停下，而是绕过去继续瞎编。所以技能会先检查：能连上收件箱吗？报价文件存在吗？是本月的吗？任何一项失败就停下并说明，而不是猜测。

4. 用 Hook 设置严苛的成功条件

Hermes 允许你在特定时刻运行自己的代码。他的规则很简单：什么都没产出，就不是成功，而是“沉默的失败”，他要在一分钟内知道。构建技能时务必设置严苛的成功判定条件——这个升级正是让另外两个升级得以成立的基础。

审批闸门：让你敢于离开办公桌的第二个升级

大多数人以为阻止 Agent 独立运行的是“能力”，其实不是——是你无法预测它会做什么。博主指出，人们普遍把审批闸门理解反了：以为闸门会拖慢 Agent，等更信任了再加。这恰恰是错的。

闸门不是限制自主性，而是创造自主性。 没有闸门，你就得盯着所有事，那不是自动化，只是更慢地自己干活。一旦存在一条它绝不会越过的硬线，你就能安心走开，去过自己的生活。

对他的回复器来说，这条线是“钱”：Agent 可以回答问题、索要信息，但一旦某个回复涉及报价、承诺日期或交付物，它就完全停下等他确认。这大约每 8 条消息只有 1 条需要他介入，其余 7 条自动完成，而他永远不会醒来发现自己“被同意”了什么。

有了边界后，调度就变得简单了。他设了一个每天早上 9 点运行的 cron 定时任务，结果直接推送到他的 Telegram——推送到你本来就会看的地方。他强调：落在你已经会看的地方的工作，才是真正发生的工作；躺在某个日志里的工作，等于没做，因为你根本不会去读。

最后一块是“撤销”。Hermes 会在修改文件前拍快照，可随时回滚，而且完全免费，却几乎没人开启。他的结论是：回滚让“行动”变安全，就像闸门让“离开”变安全。

Cron 定时任务是 Unix/Linux 系统中的定时调度机制，语法形如 0 9 * * *（每天 9:00 执行），现已被各类自动化平台广泛支持。这里的关键设计决策是"结果推送到你已经在看的渠道"——Telegram、邮件、Slack 等——而非让产出停留在系统日志里等待主动查看。这背后是一个行为设计原则：人类不会主动去轮询低优先级入口，信息必须主动送达注意力已经存在的地方才能被处理。将 Agent 输出接入既有的沟通渠道，本质上是把自动化工作流嵌入人的真实工作节律，而非要求人去适应工具的节律。

子智能体与技能瘦身：第三个升级

很长时间里他的 Agent 是线性工作的：先读收件箱、再研究发件人、再写回复，一个接一个，非常慢。解决办法是子智能体（subagents）。

这里有个多数人忽略的细节：当你委派任务时，子智能体拥有自己独立的上下文，并且只有你给它的工具。他的邮件子智能体只能读取和整理收件箱，不能发送、不能写文件——因为它压根没有这些工具。

这正是“规则”与“墙”的区别：规则只是文件里一句模型也许会遵守的话，而墙是一个根本不存在的工具。通过这一招，他同时获得了速度和安全。

还有一个几乎无人提及的隐藏成本：每个你启用的技能，在你还没输入任何内容前就已经开始消耗。 每个技能的名称和描述都会在启动时载入，好让 Agent 知道能调用什么。这是对每一条消息、每一个子智能体、每一次定时运行的永久“税收”。

于是他关掉了所有不常用的技能（不是删除，只是关闭）。他坦言自己最大的技能仍有 2.1 万 token，但整体的“地板”降下来了，上面的一切都变快了。他建议：如果重新开始，只保留 6 个每天使用的技能，其余全部关闭直到需要时再开。

一个 30 秒自检

博主提供了一个可以立刻对自己 Agent 运行的检查：统计所有已启用技能的 token 总量（包括名称和描述），算出你在输入任何内容之前就付出了多少上下文成本；再列出过去 30 天从未用过的技能。第二个数字最有价值——那些技能在每条消息上都在向你收费，却什么回报都不给。他运行后发现自己为好几个技能白白付了数周的费用。

子智能体（Subagents）是 Agent 框架中的一种任务分解模式：主 Agent 将某个子任务委派给一个独立实例，该实例拥有自己独立的上下文窗口，任务完成后将结果返回给主 Agent。独立上下文意味着子智能体不会"看见"主 Agent 积累的所有历史消息，从而显著减少每次推理的 token 消耗；工具隔离则意味着子智能体只能调用显式分配给它的能力，无法越权操作。这种设计在工程上等同于"最小权限原则"——不是靠规则约束行为，而是从架构层面消除越权的可能性，同时因为多个子智能体可以并行运行，整体吞吐量也得到提升。

四条血泪教训

博主最后总结了他犯过、并希望你不要重蹇覆辙的四个错误：

1. 不要因为一个技能“看起来酷”就添加它。 他删掉的比保留的还多，而每删一次，Agent 都变得更好。
2. 绝不让 Agent 在没有闸门的情况下执行公开或财务操作，尤其别让它替你做财务决策。
3. 不要相信任何无法向你展示其产物的成功报告——这是他犯了最久的错误。
4. 在一个你无法信任的 Agent 上叠加速度，只会让混乱和管理负担更快到来。

他强调，自己的 Agent 并没有比半年前更聪明，跑的技能反而更少。真正改变的是：他现在能预测它、它会在失败时告诉他、它会在触及重要事情前停下、而且不需要他手动启动。

这 1 万美元并非来自某个巧妙的提示词或某个新工具，而是来自“提高信任线”这件枯燥的工作——直到他可以不再盯着它。真正的问题不是“你的 Agent 还能做什么”，而是“它已经在做的事情里，有多少是你敢不检查就下注的”。

背景补充

这里所说的"信任度"本质上是一个可靠性概念：在你不亲自检查的情况下，Agent 产出结果符合预期的概率。如果信任度是 50%，意味着平均每两条产出就有一条需要人工复核，Agent 实际上只把你从"执行"解放出来，并没有从"审核"解放出来。这个乘法模型之所以重要，是因为它揭示了 Agent 自动化的瓶颈本质：在工作量和自主度已经较高的情况下，继续堆叠功能只能在"工作量"这一维度上加法增长，而信任度未提升时整体价值不升反降——更多产出意味着更多需要审核的内容涌回你的工作流。

这个区分背后有一个关键的技术原因：大语言模型的生成过程本质上是概率采样，相同的输入在不同对话（即不同的上下文窗口）中并不保证产生相同的输出，即便温度设为零也受系统提示、历史消息等因素影响。而代码（脚本）是确定性的：相同输入永远得到相同输出。因此，所有需要"精确"而非"合理"的逻辑——价格计算、日期判断、字段格式化——都应该从提示词中剥离出来，写成可执行脚本。额外的好处是脚本不占用上下文窗口，既省成本又消除了模型推理链条中的不确定性。