LLM大模型Agentic产品设计思考

Agentic AI是一种具有高度的自主性、适应性和主动性人工智能系统，与传统的 AI 系统相比，Agentic不仅仅是响应预设指令，而是能够主动设定目标、规划并执行复杂任务，表现出不同程度的自主性和代理性。这种系统能够理解复杂的环境，通过自然语言输入独立和主动地完成端到端的任务。也就是说，Agentic AI服务不仅能够理解和生成语言，还能够执行某些任务或做出决策，就像一个代理或助手一样

随着LLM的发展，能力不断提升，越来越多的Agentic应用出现，而大多数的应用都在原型验证中，比如AutoGPT，AutoGen等。即使当前来说AGI还远，但是很多产品中一些Planning与Tool Use的能力已经逐步应用了

大模型Agentic产品面临的问题和挑战

Agentic产品主要的Planning和Tool Use的能力当前还不是很成熟，即使当前效果最好的LLM模型，准确率也只能达到80%左右，当然模型的相关能力还在快速的发展。百分之八九十的准确率在AI领域已经是相当可喜的成果了，但是如果应用在商用的环境上使用，尤其是对准确性要求比较高的场景，即使有1%的错误对于用户来说可能也是100%不可信的，因为我可能要花90%的时间来找出这1%的错误，这是灾难性的用户体验。

另外当前的Agentic产品主要形态是对话机器人的形式，人从想法到表达到语言到理解到执行，每一步都存在信息损耗，这些损耗对于一个确定性产品来讲很可能是不可接受的，这很容易让人想起客户想要秋千和最终的交付的产品的漫画，这里就体现了各种的信息损耗。人的想法和表达是千变万化的，但是系统解决的问题是固定的。如何将一个开放域的问题对齐到一个封闭域而降低信息损耗，这也是一个很重要的问题。

总结来说，要做好Agentic产品面临的几个关键的问题与挑战：

• 用户表达自己真实想法的准确性
• 语言表达本身的准确性与歧义性
• LLM理解语言本身的准确性
• LLM去规划执行任务的准确性
• 其他复杂处理的准确性… 整个流程下来，我们发现如果我们把各个节点当作独立事件，那即使单点问题准确解决的概率很高，一串下来最终的准确率也很低了。

想想一下这个场景，我们面对一个对话机器人，想问一个问题但是细想之下又不知道该问什么，怎么问，想好怎么问输入到对话框里结果还输入了一些错别字，发送以后机器人给了一堆不着边际的答复，跟自己所想甚远，最后骂了一句sx产品，然后就关掉走开了…

怎么设计一个好的Agentic应用处理流程

当前的类似产品上来看，绝大多数采用的结构类似于：

当然这只是一个简化的图，实际上的应用会更加复杂，比如结果返回之前需要llm重新润色，llm计划过程可能是一个递归的过程，可能涉及Tools的使用等 这种交互范式一些开放式问答类应用还是ok的，因为我们并不在意结果的准确性与否，或者对于结果的准确性我们并不十分在意，应用更多给我们的是启发性的知识

而在一些对准确性要求更高的场景，比如我们期望应用帮我们做数据分析、帮我们做应用控制等等场景，我们更期望得到一个确定性的结果，这里前面各种不确定性的动作要求就高了。 在这种场景下我们该如何设计应用流程呢？可能有几种方式

• 后验式：分析后执行完以后将执行计划与结果一同返回给客户端，客户端同时展示，交给用户判断是否存在
• 先验式：将不确定的事情前移，通过与用户的交互来完成系统与用户的人机对齐，而对齐后的结果再交给系统执行，类似于这种交互流程

对齐的过程其实就是告诉用户我准备干什么以及准备怎么干，这个一个很简单的设计原则，不要让用户猜你的系统干了什么 当然，如果干什么都要让用户确认，那种产品设计也很难让用户接受，不满足产品简单易用的原则，交互设计的越复杂对于用户来说越难用

这就给产品设计提出了一个很大的挑战，如何做一个又清楚又简单的交互设计可能是做类似产品的一个关键挑战

传统知识问答类应用通过运行提示与引用标注来与用户对齐

类似的知识问答类agent通过自动搜索等工具来回答用户问题，这种交互方式是在回答中以及回答后给出用户回答使用的工具，引用了哪些知识，在回答那里使用的，等等信息以标注说明等方式给到用户，这其实是一个后验式的交互设计，我先告诉你答案，并告诉你我怎么得到的这个答案，你根据这些信息来判断我回答的对不对，是不是你想要的

这种交互可以说是现在使用最多比较常见的对齐方式，有很多优点比如技术实现简单，用户操作简单，适用于对准确性一致性要求比较弱的场景，所以也存在几个问题

• 对系统影响不可控：如果有对系统存在影响的CUD操作，无法解决先确认后执行的问题，如果存在问题可能对系统导致影响
• 验证复杂度较高：后验信息较多，用户实际确认复杂度较高，实际上用户可能不会实际去确认使用

准确性要求较高的GA数据分析采用先对齐的策略与用户交互

GA推出了一个辅助数据分析的功能，在实际使用时，用户问题会实时的传到后台进行问题的分析，并转换成一个具体的动作（以标准化问句体现，背后是明确的计划与动作），用户选择后后面执行执行相关计划 这种交互不但简化了用户确认的过程，而且给到用户一个相对明确的答案，虽然交互上增加了一步，但是总体来讲是利大于弊的

其他可能的先验式交互方式设计

在交互设计上，我们主要的目标是即完成“用户想干什么”与“我能干什么、我想怎么干”这两个问题的对齐，又不能给用户太差的交互体验，一些可以用的方法包括：

• 类Terminal的Tab问题补全：根据用户的输入整理计划并灰化显示可替换的问题，通过Tab的交互自动调整优化问题
• 类车载导航的二次确认机制：根据用户的输入分析后给一个确认的界面，让用户选择明确问题或计划
• 多轮对话确认机制：针对复杂问题给出分析的结果输出给用户，让用户选择是否执行或调整
• … 其他更多更方便更准确的对齐交互方式希望与各位讨论