Agent不是产品，交付才是——怎么让客户用得住

你花了两周搭好一个Agent，自己用得很顺。

帮客户处理咨询、整理需求、生成初稿——每个环节都跑通了，你演示的时候效果很好，客户也满意。然后你把它交出去了。

第一周，客户发来消息：Agent给出了一个奇怪的回复，客户不知道是不是该相信它。第二周：Agent做了一件它本来不该做的事，不知道怎么回事。第三周：出了问题，客户不知道该怎么处理，来找你。

你去查，Agent本身没有问题。它的行为，在你的使用习惯下是完全合理的。

问题出在交付。

你交出去的是一个工具，但客户需要的是一套可以独立使用的系统。 这两件事之间的差距，不是功能问题，是知识问题——你对这个Agent积累了两周的隐性理解，什么指令有效、哪条边界不能碰、出了什么问题怎么处理，这些全在你脑子里，一个字都没交出去。

Agent不是产品，交付才是。把Agent搭好只是开始，让客户用得住才是真正要解决的问题。

NotebookLM的音视频概览，解读的比较通俗易懂，对于时间比较紧张的读者朋友，可以听听，会有启发。

为什么"自己用顺了"是个陷阱

搭Agent的人有一个几乎无法避免的认知优势：他们知道这个Agent的"脾气"。

哪种描述方式会让它理解准确，哪种描述方式会让它跑偏——这是经验，不是文档。什么时候的输出可以直接用，什么时候需要复核一遍——这是判断，不是规则。出了问题先检查什么，怎么把任务重新拉回正轨——这是肌肉记忆，不是手册。

这些知识是真实存在的，但它们存在于创建者的脑子里，不存在于任何可以转交的地方。

客户拿到Agent之后，面对的是一个没有这层知识的工具。在他们眼里，Agent的行为有时候清晰，有时候莫名其妙，出了问题也不知道从哪里入手。这不是他们用法有问题，是他们缺少了使用这个Agent所需要的隐性前提。

好的交付，本质上是一次知识转移。把隐性知识显性化，是整个交付设计里最核心的工作。

交付前：权限要重新设计

自己用Agent的时候，权限往往是"够用就好"——有时候为了方便，会开得稍微宽一些。交给客户之前，这个权限配置必须重新审视。

原则只有一个：客户第一次使用时，能出的最大问题，必须在你可以接受的范围内。

从三个维度收紧权限：

能访问什么。 数据库、文件系统、外部API——客户在这个使用场景里需要访问哪些数据，只给这些。不需要访问的数据，即使开了权限也没有用，但一旦Agent出现误操作，这部分数据就成了爆炸半径的一部分。

能做什么操作。 读取、写入、删除、发送——根据实际使用场景，只开必要的操作类型。读取信息的Agent，不应该有写入权限；生成草稿的Agent，不应该有直接发送的权限。写操作和删除操作，是权限配置里最需要谨慎的两类。

能做到哪个范围。 同样是写入权限，能操作哪些记录、哪些客户的数据、哪个文件夹，边界必须明确。范围不明确的权限，是事故发生时追责最难的地方。

权限设计不是一劳永逸的。随着客户对Agent的使用逐渐成熟、信任逐渐建立，权限可以阶段性地扩展——但起点必须保守，不能反过来。

交付时：文档是真正的产品

Agent的系统提示词、工作流配置、工具设置，这些是技术实现。文档，才是交到客户手里的产品。

文档不是给技术人员看的，是给第一次使用这个Agent的普通用户看的。检验标准只有一个：一个完全不了解这个Agent的人，看完文档能不能独立完成一个任务，出了问题能不能自己处理。

有五件事必须写清楚：

这个Agent能做什么，不能做什么。 能做什么，决定了客户知道去哪里用它；不能做什么，同样重要——甚至更重要，因为客户在不知道边界的情况下，最容易在边界附近出问题。两件事都要写，而且要写得一样明确。

怎么给它任务。 有效指令长什么样，提供两到三个具体例子。然后反过来写：哪些描述方式容易导致理解偏差，举出来。这部分是最值得花时间的，因为指令质量直接决定输出质量，而客户在这里最容易踩坑。

结果怎么验收。 Agent做完之后，客户怎么判断结果是对的？验收标准是什么？如果没有明确的验收标准，客户要么过度依赖Agent的输出不加核实，要么对每个结果都持怀疑态度不知道该不该用。两种情况都不好。

出错了怎么处理。 把你自己遇到过的常见错误类型列出来，每种对应一个处理方式。客户遇到问题时，第一反应不应该是找你，而是翻文档——文档设计好了，你才能真正从这个Agent的日常维护里脱身。

什么时候必须找人。 超出Agent能力范围的情况，必须明确列出来，告诉客户遇到这种情况应该找谁、怎么联系。这不是承认Agent不够强，是在帮客户建立正确的使用预期——知道边界在哪里，才能在边界内放心用。

交付后：把"别踩这条线"变成系统约束

文档写了"不要做X"，但人会忘，会误操作，会在某个时刻觉得这条规则可能不适用于这种情况。越靠近人的约束越容易被跳过，越靠近执行层的约束越可靠。

把边界条件从文档建议变成系统约束，有三个层次：

提示词层面的硬编码。 在Agent的系统提示词里明确禁止某些行为——不是提醒，是禁止。比如"不要在未经确认的情况下提及具体价格"、“回复中不包含任何客户的个人联系信息”。这层约束是Agent的内置护栏，不依赖客户记住文档里的某条规则。

工具层面的权限限制。 根本不给Agent开它不该有的工具，从源头消除某类风险。Agent没有发送工具，就不会发出任何东西；Agent没有删除权限，就不可能删掉任何数据。这层约束是最可靠的，因为它不依赖Agent的判断，也不依赖用户的操作。

输出层面的过滤。 对Agent的输出设置过滤层，某些内容类型——比如涉及法律责任的表述、超出服务范围的承诺——不允许直接输出给客户。这层约束是最后一道防线，捕捉前两层没有拦住的情况。

三层约束叠加，不是因为单层不够，是因为每层的覆盖范围不同，组合起来才能把风险压到可以接受的水平。

交付之后：反馈机制才是长期稳定的保障

文档写完、权限设好、约束部署好——交付还没有结束。

客户开始真实使用之后，会遇到你没有预见到的情况：指令方式和你预期的不一样，使用场景比你设计的范围稍微宽一点，某类问题反复出现。这些不是失败，是信息——是改进文档、调整配置、完善约束最好的原材料。

建立一个简单的反馈收集机制：客户遇到问题时有地方记录，你定期回顾这些记录。头几次出问题，不要直接替客户解决——先让他们按文档尝试，看文档能不能覆盖这个情况。文档覆盖了，这次问题解决了，客户也学会了一种处理方式。文档没覆盖，说明文档有盲区，补上去。

客户使用前三个月产生的问题记录，是这个Agent最有价值的质量文档。 比你在交付前写的任何假设都更接近真实使用场景。

写在最后

搭好Agent是技术问题，交付好Agent是设计问题。

权限收紧到最小安全集，文档写到陌生人也能独立使用，边界条件落到系统约束而不只是文字提醒，反馈机制建立起来持续改进——做完这四件事，你交给客户的才是一个可以独立运转的系统，而不是一个只有你能驾驭的黑盒。

Agent不是产品，交付才是。

感谢你看到最后，如果你觉得有启发，随手点个赞、在看、转发吧，如果想第一时间收到推送，也可以给我加个星标⭐我们下期见。

我是「AioGeoLab」主理人塔迪Tardi，AioGeoLab是深度洞察AI第一性原理和应用实践的前瞻性研究实验室，目前有两个主要研究方向：

「塔迪GEO判断工程」是基于GEO的价值SEO化，在AI从“说”到“做”的重要跃迁阶段，试图回答，如何让AI敢于行动、不因为责任问题而畏手畏脚，而做的一个前沿研究项目。

「塔迪硅基禅心」是传统东方智慧、未来AI前沿、当下应用实践，深层共鸣的探索。不是用AI解读经典，也不是用经典指导AI。 这是一场跨越2500年的对话，在算法与古老智慧之间，照见意识、智能与存在的本质。
塔迪的微信 - tardyai2025。