产品经理必读：AI Agent 落地踩坑与正确姿势

AI agent 是世界上 demo 最容易的东西，也是上线最难的东西之一。

demo 能跑通是因为你把它引向了一条你早已熟悉的路径。生产环境不一样。真实用户会问没有人预料过的问题，模型有时会编造答案，成本随用量增长，而一个自信满满的错误答案会造成实质损害。

这些并不意味着你不应该做 agent。它意味着你应该审慎地、按特定顺序去构建它。

你真的需要 agent 吗？

这个词涵盖了三种截然不同的东西，选错了会浪费数月时间。

单次模型调用接收一个输入并返回一个输出。总结这个。分类那个。起草一个回复。如果这能解决你的问题，就这样干。它更便宜、更快速，而且远更容易保持可靠。

检索（Retrieval）是用你自己的文档来回答问题。模型拿到相关文本后被要求从中回答。这才是大多数人说"AI agent"时真正指的东西，而且它比真正的 agent 简单得多。

真正的 agent 会规划、选择工具，并在朝向目标的多个步骤中采取行动。只有当任务确实需要根据上一步的结果来决定下一步做什么时，你才需要这个。

来找我们咨询 agent 的大多数产品需要的其实是前两种之一。从那里起步不是退而求其次，而是工程上的正确选择。

范围应该有多窄？

比你感觉舒适的范围更窄。

在生产环境里失败的 agent 是那些被要求"尽量提供帮助"通用型 agent。真正能用的 agent 被赋予了明确边界的特定工作，它们会拒绝所有超出范围的任务。

我们的潜在客户生成 agent 不聊天。它只查找潜在客户信息、起草一份个性化提案，然后交付。正是这种窄化让它可以在无人盯着每一步的情况下运行。

写代码之前先写下三件事：

Agent 被允许做什么

在任何指令下都绝对不能做什么

当它不确定时应该怎么做

第三项最重要，但它往往是留空的。

它需要什么样的护栏？

玩具和产品之间的差距，在于模型出错时会发生什么。不是"会不会"的问题，是"何时"的问题。

限制工具。Agent 只能通过你赋予它的行动来造成危害。只读工具是安全的。发送、扣费或删除类的工具需要确认和硬性限制。

检查每一个输出。如果 agent 返回结构化数据，在任何系统对其采取行动之前先验证它。永远不要把原始模型输出直接灌进一个会做真实操作的系统。

让它说"不知道"。当不确定时能转交给人类的 agent，价值远高于总能给出答案的那个。自信但不正确才是全部风险所在。

记录一切。你无法改进你看不到的东西。每一次输入、工具调用和决策都应该能在数月后追溯。

如果你的 agent 读取邮件、文档或网页，假设其中部分文本会试图给它下命令。任何来自外部的内容都是待处理的内容，不是待执行的命令。

如何控制范围和延迟？

上线后让团队意外的两件事：账单，以及用户等多久。这两个都在设计阶段就决定了。

成本方面，按难度分流。把简单的大多数请求发给小而快的模型，把大模型留给真正困难的情况。积极缓存，因为用户问题重复的频率远高于人们预期的。限制 agent 可以采取的最大步骤数，这样一个困惑的循环不会在深夜悄悄跑出一笔账单。

速度方面，流式返回响应让用户立即看到进展。把独立的工作同时做而不是顺序做。对于哪些部分真正需要即时回答要诚实，因为大量有用的工作可以在用户做其他事情的同时在后台进行。

如何知道它真的能用？

"我试的时候感觉没问题"不是测试。

上线之前，收集一组有已知正确答案的真实例子。包括那些奇怪的、粗暴的、以及专门设计来欺骗它的例子。然后在每次修改 prompt 或模型时都对照这个集合来测量。

没有这个，每一次改进都是猜测，你会在无声中破坏东西。一个你真正运行的小测试集，胜过一个大到你只是自我感觉良好的测试集。

保存失败案例。每次 agent 在生产环境中出错，把那个确切输入加到你的测试集中。几个月后，这个集合的价值超过你一开始能写出来的任何东西。

应该怎么上线？

低调地上，面向一小部分人。

部署到一小部分流量上，并且要有一个人能看到它在做什么，以及一个能在几秒钟内关闭它的开关。看日志而不是会议室里的感觉。

在有十分之一用户的阶段第一周发现的失败，比在全员阶段发现的失败代价要低得多。而且全员阶段的失败往往发生在周末。

用这种方式做的话，AI 功能就不再是你承担的一个风险，而变成你可以依赖的产品的一部分。其下的检索、prompt 和评估层讲的是如何正确地集成 LLM，而我们构建的主要是这些工程部分，而不是模型本身。

选能完成工作的最简单工具。给它一个边界清晰的工作。优先构建护栏，有意识地决定成本和速度，用真实例子而不是感觉来测试。

然后小规模上线，密切关注，等到日志变得无聊之后再扩大它。