整体概述
此只为针对 AIP 开源多Agent平台，且为临时手稿，带有口语化，仅以参考为主。
在本地化的沟通过程中，我们遇到了一系列实际问题，并在此基础上进行了总结与产品能力的提升。
鉴于当前在相关领域缺乏明确的范式可供参考，本文旨在提出适用于下一步的落地范式。整个升级过程紧紧围绕 “聚焦” 二字展开，在于实现 ToB 业务的拓展以及向 ToC 场景化的延伸。
由于概念过快，业务大模型对技术的探索性，前期重点会放在ToC，能力体现是私有化和SaaS化，使得Agent落地范式更加明确，具体而言，将在以下几个关键方面进行优化：
明确场景结合方式：使多Agent与各类场景的融合方式更加清晰明了，从而提高系统在不同场景下的适用性和效率。
降低成本与增强私有化：紧密结合业务场景，实现更低成本的运作模式，同时强化私有化部署的能力，满足客户对数据安全和个性化定制的需求。
引入原生大模型应用思维：摆脱传统软件开发思维的束缚，充分利用原生大模型的优势，构建更加智能、高效的应用体系。
深入探索业务场景：将更多精力投入到对业务场景的深度挖掘中，精准把握客户需求，提供更贴合实际业务的解决方案。
提升通用场景的通用性：在切入通用场景时，进一步增强系统的通用性，让用户能够直接便捷地使用，减少复杂的配置和调整过程。
以下为通用法律AI场景，智能体角色：
更为具体的场景结合：
为确保升级方向的正确性和落地范式的有效性，我们遵循以下基本原则：
场景明确性：Agent 必须针对特殊且明确的场景进行设计，避免多业务场景的混合应用。即使不同Agent的工作流看似相似，也应严格区分，以保证系统在特定场景下的高效运行和精准服务。
场景深度：Agent 需要深入特定场景，简单的Agent往往能力有限，难以充分发挥作用。应避免构建能力过低的Agent，确保其能够在相应场景中体现出足够的价值。
技术主导与客户反馈结合：Agent 由技术团队负责建立，客户主要负责提出需求以及提供使用反馈。通过这种分工模式，有效避免Agent在设计和功能上出现鸡肋的问题，确保其能够切实满足客户需求。
业务专家参与：Agent 的建立需经过业务专家的充分讨论。对于非专家参与构建的 Agent，暂不考虑纳入应用范围，始终将重点放在能够体现高价值的Agent构建上。
符合大模型原生应用：Agent 应充分契合大模型原生应用的特性，避免局限于传统的单一输入框工作流思维模式。要积极探索和构建符合原生大模型特点的应用形式，充分发挥大模型的强大功能。
每个设计师有不同的设计，我有我思，期望有兴趣的同学多交流。
平台形态
平台基础形态通过SaaS化的形式对外提供能力，直接提供场景化的Agent能力。
单Agent向多Agent延伸
去掉ChatBox思维，一个输入框架是不能解决业务问题，而是需要结合业务场景框架。
在传统的交互模式中，ChatBox 思维存在一定的局限性，仅仅依靠一个输入框架往往无法有效解决复杂的业务问题。我们需要结合具体的业务场景框架，构建更加灵活和高效的交互体系。在实际业务场景中，单个Agent常常难以独立完成所有任务，因此，将多个Agent组合起来协同工作，形成协作模式，成为必然的发展趋势。
例如，在 AIP编写文档和文档审核的场景中，可分别设置负责内容创作的Agent和专注于文档审核的 Agent。
负责编写文档的Agent能够根据给定的主题和要求，快速生成高质量的文本内容；而负责审核的Agent则可以从语法、逻辑、专业性等多个维度对文档进行全面审查，提出修改建议。
在频道（群）场景下，多Agent协作也能发挥巨大优势。不同的Agent可以分别承担信息收集、话题引导、答疑解惑等不同职责，共同营造一个活跃且有序的交流环境。
传统软件思维要去掉
大模型的出现，极大地拓展了软件应用的边界，其能力远远超出了传统软件形态的范畴。我们不能再将思维固化在传统软件模式中，而应积极探索更加丰富多样的形态。这种丰富性不仅体现在语音交互等常见形式上，更体现在整体交互模式的创新上。
例如，传统软件可能主要依赖于用户手动输入指令来执行操作，而基于大模型的应用可以通过对用户行为、语言习惯、历史数据等多方面的分析，实现更加智能化的主动服务。
用户无需明确输入指令，系统便能根据对用户需求的理解，提前准备相关信息或提供合适的建议，从而为用户带来更加流畅和便捷的使用体验。
业务场景需要要明确
大模型的能力是超出了传统软件形态的模式，不要固化在传统软件形态，会显示更加丰富的形态，而不仅是指语音，而是交互模式。
在实际推广和应用过程中，不能给客户一种 “什么都能做” 的模糊印象。因为这种宽泛的表述往往意味着在实际操作中可能什么都做不好。
我们必须明确系统所针对的具体场景，以 RAG（检索增强生成）技术为例，其在不同领域和业务流程中可能衍生出 N 多个具体场景，以下为AIP不同场景工作台：
只有将这些场景明确界定，才能让客户清楚了解系统的适用范围和实际能力，从而增强客户对产品的信心，避免陷入 “看似全能，实则无力” 的尴尬境地。
比如，在医疗领域，RAG 技术可应用于辅助医生进行疾病诊断，通过检索大量的医学文献和病例数据，为医生提供诊断建议和参考依据；而在金融领域，RAG 技术可用于风险评估，通过对市场数据、企业财务报表等信息的检索和分析，帮助金融机构评估投资风险。
Agent需要要专业
Agent 要具备更高的专业性，深入到特定场景的核心环节。这不仅体现在其具备强大的交互能力，还体现在其能够整合记忆、数据以及模型训练等多个方面，并将这些环节实现交付工程化。模型并非一成不变，Agent 也需要不断进化。它应具备自主学习能力，能够根据每次对话和任务执行过程中积累的数据和经验，进行自主训练。同时，Agent 还应具备反思和总结的能力，能够对过往的工作进行复盘，分析其中的优点和不足，从而为下一次对话和任务做好更充分的准备。
将这些过程形成标准化的工程流程，有助于提高Agent的性能和稳定性。以 AIP 在Agent到记忆、反思的过程为例，Agent 在与用户交互过程中，会将用户的问题、提供的信息以及自身的回答等数据进行记录和存储，形成记忆。
以下为AIP的Agent设计模块和反思演化架构：
在后续的交互中，Agent 能够检索这些记忆，更好地理解用户需求和提供更准确的回答。
同时，Agent 会定期对这些交互数据进行分析和总结，反思自己在回答过程中存在的问题和不足之处，然后通过自主训练优化自身的模型和策略，以提升下一次交互的质量。
Agent需要搭配数据
Agent 作为最终与用户交互的形态，其背后离不开强大的数据支持。在后台，需要对原始数据进行一系列的处理流程，包括数据收集、清洗、整理等。
通过这些步骤，将杂乱无章的原始数据转化为有价值的信息，最终形成Agent的知识库。这个知识库不仅包含了丰富的知识内容，还融入了业务思维，能够帮助Agent更好地理解业务场景和用户需求，从而提供更符合实际业务的解决方案。
例如，在电商领域，Agent 的知识库中应包含商品信息、用户购买历史、市场趋势等数据，通过对这些数据的分析和利用，Agent 能够为用户提供个性化的商品推荐、解答用户关于商品的疑问，并协助商家进行市场分析和决策制定。
总结
以上内容是基于前期在客户场景下与多Agent沟通的实践经验，总结得出的业务落地范式。我们衷心期望对该领域有兴趣的同学能够积极参与交流，共同探讨，进一步完善和优化多Agent平台的升级和落地策略，推动相关技术在实际业务中的广泛应用和发展。
