最近看了一篇文章，麦肯锡的《Agent落地一年：一线团队的6个教训》，觉得很有道理，今天分享给大家。需要说明的是，本文不是简单的翻译，而是我的二次解读。Agent太火了，以致于大家都在问一个问题：Agent如何落地？这种对Agent的过度关注，可能导致一个问题：Agent确实是跑起来了，看起来也很厉害，但是并没有真正的改善工作绩效。比如，我们可以让Agent来生成招聘JD信息，看起来很厉害，但其实价值有限。正确的做法应该是梳理整个招聘流程，找到其中的痛点，再寻找合适的技术来解决痛点。比如，对于蓝领招聘来说，JD编写是痛点吗？其实不是。真正的痛点是海量面试的人力成本，以及低下的招聘效率（人手限制）。明确了这些痛点，我们就能用合适的技术来重构整个蓝领招聘流程。比如，我们可以用大语音模型和数字人来模拟面试官，利用征信接口来验证候选人的征信状况，利用图像技术来识别候选人的肢体健全程度。通过这种组合，可以让整个面试流程实现100%自动化，自然就能解决蓝领面试的痛点。Agent更适合灵活多变、非标的工作，比如员工陪练，哪怕是同一个员工的培训，每一次的对话内容可能都不一样。但是，对于稳定、标准化的工作，比如，录入一张销售订单，强行使用Agent只能适得其反。实际上，根据我的观察，很多企业级原生AI应用，大模型“含量”都不足50%：即绝大部分工作其实都高度依赖工作流、传统算法、传统软件工具等。也就是说：真正能落地的企业级AI应用，大模型只是众多工具中的一个，因此千万不要试图用大模型去解决所有问题。很多企业陷入一个误区：Agent落地之前，认为Agent无所不能；Agent落地以后，又觉得Agent啥都不行。其实，部署Agent就像招聘一个员工，也需要持续培养，直到他达到企业的要求。比如，搭建了一个内部知识库Agent，但是回答质量非常糟糕。比如主要原因是用户提问过于模糊，导致RAG知识库匹配不准确。那么我们可以让Agent具备“追问”的能力，如果用户提问模糊，则会自动追问，引导用户把问题关键信息补全。比如，用户问“创建失败了”，Agent就可以追问：切记：Agent的搭建是一个非常细致的工作，就像编写程序一样，需要持续的调优。永远都要重视Agent的评估工作，特别是当公司部署了成百上千个Agent，一旦最终的结果出现了问题，要找到是哪个步骤导致的问题，就会非常困难。因此，应该在工作流中内置监控和评估机制，使得每个步骤的执行结果都可以被跟踪和评估，这样一旦出现了问题，才能快速定位和解决问题。就像新产品的研发一样，在早期，为了快速验证MVP，我们会为每一个任务创建专门的Agent，比如专门处理“补差价”的Agent。实际上，Agent也要注重标准化设计，即追求较高程度的复用率，从而减少开发和维护的成本。举个例子，“补差价”Agent的很多步骤在“售后”场景下都可以复用，包括验证用户身份、查询用户订单、查询售后政策等。比如，在“退货”场景下，Agent同样需要验证用户身份、查询用户订单、查询售后政策。因此，可以创建一个“售后”Agent，再把“补差价”场景纳入进去，这样就可以减少不必要的开发和维护工作。我们必须认识到，大语言模型的底层逻辑决定了，他做不到100%准确，因此，对于那些较为严谨的业务场景，一定要注重人机协同。
而做到这一点的关键，就在于开发简洁的可视化用户界面，让人们能够轻松与智能体互动。
比如，在ERP系统中，我们可以让Agent自动生成订单分析报表，与此同时，也必须同时提供“展示和修改数据筛选字段”的页面。
这样一方面方便用户核实报表生成的准确性，另一方面也可以让用户在Agent生成结果的基础上，进一步深入分析。
过去，我们曾经争论：对话式交互界面会不会彻底取代传统的人机交互界面，从“人机协同”的角度来看，我认为，未来这两个界面会长期共存。
