文章探讨了AI代理架构中产品经理应关注的核心问题，指出高准确率和快速响应并不足以确保用户持续使用。关键在于通过架构设计提升用户体验和信任感，尤其是在处理复杂问题时。文章通过具体案例说明，如何通过合理的产品决策让AI代理显得“神奇”而非“令人沮丧”，并强调了信任建立的非常规方法。

产品经理指南：AI代理架构——为何能力不等于采用率

最近，我与一位产品经理交流，他在过去几个月内推出了一个AI代理。尽管数据显示表现优异：89%的准确率、亚秒级的响应时间、用户调查中的积极反馈，但用户在遇到实际问题时却迅速放弃使用该代理。例如，一位用户同时遇到账单争议和账户锁定问题，代理无法有效处理，导致用户转而寻求人工帮助。

这种现象在许多产品团队中普遍存在，他们过于关注让代理“更智能”，而忽视了架构决策对用户体验和信任感的影响。本文将深入探讨AI代理架构的各个层面，解释产品决策如何决定用户是否信任并持续使用代理，以及为何有些代理让人感到“神奇”，而另一些则令人“沮丧”。

架构决策的关键层面

1. 记忆层：代理应记住多少信息，以及保留多久？

   • 记忆不仅仅是技术存储，它关乎创造理解的假象。代理的记忆决定了用户是在与机器人对话，还是与一位知识渊博的同事交流。
   • 记忆类型包括：会话记忆（当前对话）、客户记忆（跨会话的互动历史）、行为记忆（使用模式）、上下文记忆（账户状态、订阅情况等）。
   • 记忆越多，代理越能预测需求，而不仅仅是回答问题，但这也增加了复杂性和成本。

2. 集成层：代理应连接哪些系统，以及拥有何种访问权限？

   • 代理与用户工作流和现有系统的连接深度决定了用户是否难以切换。这一层决定了代理是工具还是平台。
   • 集成越多，代理越有用，但也增加了潜在的故障点，如API速率限制、认证挑战和系统停机。
   • 成功的代理通常从2-3个关键集成开始，然后根据用户需求逐步扩展。

3. 技能层：代理应具备哪些具体能力，以及这些能力的深度如何？

   • 技能层是代理与竞争对手较量的关键。重点不在于功能的数量，而在于是否具备创造用户依赖的正确能力。
   • 例如，支持代理是否仅能读取账户信息，还是能修改账单、重置密码和更改计划设置？每项额外技能都增加了用户价值，但也增加了复杂性和风险。

4. 信任层：如何衡量成功并向用户传达代理的局限性？

   • 这一层决定了用户是否对代理产生信心，还是在第一次错误后放弃使用。信任不仅关乎准确性，还关乎透明度。
   • 信任策略包括：信心指标（如“我有85%的信心解决此问题”）、推理透明度（如“我检查了三个系统，发现…”）、优雅的边界（如“这是一个复杂的账单问题，我将为您转接专家”）、确认模式（何时请求许可，何时直接行动并解释）。

架构实施方式

1. 单一代理架构：

   • 所有操作在一个代理的上下文中完成。简单易建，易于调试，成本可预测，但处理复杂请求时可能变得昂贵且难以优化。

2. 路由代理架构：

   • 路由器识别用户需求后，将任务分配给专门的技能模块。这种方式更高效，但技能间的协调可能变得复杂。

3. 工作流代理架构：

   • 预定义常见场景的逐步流程。适用于合规性强的行业，但面对用户边缘案例时可能显得僵化。

4. 多代理协作架构：

   • 多个专门代理通过A2A协议协作。虽然能处理复杂问题，但引入了安全、计费、信任和可靠性方面的复杂性，目前仍处于探索阶段。

信任的关键：透明度与诚实

用户并不信任总是正确的代理，而是信任那些在可能出错时诚实的代理。代理应准确校准信心、展示推理过程，并在达到能力极限时优雅地转接给人工支持。

在第二部分中，我们将深入探讨代理的自主性决策，包括何时请求许可、如何平衡自动化与用户控制，以及实际实施中的治理挑战。

评论内容总结：

1. 关于AI自信度校准的质疑

   • 评论1指出，AI的自信度校准存在问题，当前的LLM技术无法确保其自信度与实际准确性一致。
   • 引用：“When your agent says it's 60% confident, it should be right about 60% of the time. Not 90%, not 30%. Actual 60%.”
   • 引用：“With current technology (LLM), how can an agent ever be sure about its confidence?”

2. 对AI模型能力的现实评估

   • 评论2和评论5强调，AI模型虽然复杂，但其能力有限，不应过度夸大或期望通过简单的工作流提升其能力。
   • 引用：“Stop trying to treat these things as more than they are. Stop trying to be clever.”
   • 引用：“In short: nice industry roadmap, but we are nowhere near robust, trustworthy multi-agent systems yet.”

3. 对PM角色的讨论

   • 评论4和评论8认为，PM应专注于用户需求和范围，技术细节应由工程师负责，且大多数PM无法有效使用技术框架。
   • 引用：“In my book they ideally focus on understanding scope, user needs and how to measure success.”
   • 引用：“As an engineer, I like this framework but can think of approximately zero PMs who could use it to build a product.”

4. 对AI客服的实践经验分享

   • 评论6和评论7分享了AI客服的实践经验，强调应逐步过渡到AI客服，并确保在AI无法处理时及时转人工。
   • 引用：“My view is that you need to transition slowly and carefully to AI first customer support.”
   • 引用：“I MVP'd one of these (a basic sequence of LLM customer support 'agents') at my last job.”

5. 对技术框架的认可与批评

   • 评论3和评论5认为，文章提供了有用的技术框架，但实际应用中仍存在许多技术挑战。
   • 引用：“I found this to be a decent overview of how to reason about building these systems from first principles.”
   • 引用：“Nice framing for PMs, but technically it is way too rosy.”