1）AI Agent被誉为AI领域的终极应用：2023年3月，开发人员Significant Ggravitas在GitHub上发布了开源项目AutoGPT，它以GPT-4为驱动基础， 允许AI自主行动，完全无需用户提示每个操作。

2）游戏领域应用：西部世界小镇，2023 年4月斯坦福大学的研究者们首次创造了多个智能体生活的虚拟环境《斯坦福西部世界小镇》，这是一个交互式的沙盒环境，在小镇上，生活着 25 个可以模拟人类行为的生成式AI Agent。它们会在公园里散步，在咖啡馆喝咖啡，和同事分享当天的新闻。

3）智能体国内发展：2025年被誉为智能体元年；大模型技术的发展、平台的发展、终端厂商的发展、应用厂商的发展共同推进生态的演进。

智能体的核心结构为规划、行动与记忆，具体如下：

首先，智能体接收用户信息，并基于这些信息进行规划。规划即在理解用户意图后，分析解决问题所需的步骤，通过自主思考形成思维链。随后，智能体根据规划采取行动。规划实则是一份行动列表：为实现最终目标，需将任务拆分为多个部分，并确定所需行动。

在行动过程中，需要调动相关工具，这些工具包括但不限于传统认知中的HTTP接口和代码块。随着技术发展，尽管有Function Call和MCP协议的引进，但本质上它们仍属于工具范畴，协议的发展无非是把工具分装得更便于智能体理解、调用和识别。

在交互过程中，智能体需进行连续对话并具备对历史场景的感知能力，因此具有记忆功能。同时，智能体配备知识库，将已学习的内容作为长期记忆进行存储，其相当于向量数据库。此外，其演进需要结果反馈，以此评估其运行效果。

无论是分析、总结还是检索，智能体整体效果主要取决于大模型的能力。此外，效果的提升也依赖于数据质量，即具备优质的知识储备。当前通用智能体（即大模型完全自主思考、分析和处理场景）解决垂类场景问题的效率较低，仍需遵循标准化流程来处理。另外，产品化场景落地需要融合各类应用，针对不同的意图匹配对应的智能体。

智能体的演进主要分为四个阶段。

1）问答智能体（检索+总结）

• 技术方案：构建知识库、RAG、LLM。

   

• 优点：简单快速，在简单的问答场景或者原有的知识问答或者客户服务场景中效果较好。

   

• 缺点：无法处理复杂的问题，召回的准确率不可控。例如，用户的问题与知识库中的内容本质上没有联系，但如果语义上相关联，会召回不相关的知识。

   

• 典型场景：FAQ、知识库查询。

2）SOP智能体（预定义流程编排）

• 技术方案：允许预先设定标准流程。

   

• 优点：标准化，专业可控和高效。

• 缺点：

• 处理的灵活性较差，一旦用户改变需求或者需要处理的流程与预设不符，便不太可行；

   

• 流程的可维护性较差，每次发布都需要重新编排流程、验证和发布。

• 典型场景：适用于AI搜索、数据指标分析，以及OA中的流程审批等场景。

3）通用智能体（反思+规划+执行）

• 技术方案：这种模式属于反思大模型，例如Manus，它支持一些外部工具及虚拟机的调用。其良好效果的实现，主要得益于大模型的发展、工具调用和MCP工具的开发。

• 优点：灵活、适应和推理规划能力强。

• 缺点：

• 模型和Token消耗大，处理不稳定；

   

• 不可追溯，调试较为困难；

   

• 出错的风险高。

• 典型场景：开放问题求解、个人助理

通用智能体更适合协助探索性任务或者解决开放性问题，但在运维、审批这类标准化流程中则没有必要，且结果往往不稳定。

4）协同智能体（专业+多角色协同）

• 技术方案：构建智能体的关键在于大模型与知识，但需求分析与编码所需的知识和模型能力则截然不同。针对专业需求，需做好知识沉淀，并对模型开展微调、预训练与强化学习，这涉及到向不同专业领域拓展。一旦确定各专业领域对应的模型及知识，提示词工程的设计也会随之不同。各领域相互独立，通过数据交流，可采用A2A协议或其他适配协议。

• 优点：专业、鲁棒性强、解决复杂专业问题

• 缺点：系统复杂度、成本和通信要求高

• 典型场景：自主软件开发以及咪咕的智能解说、预测分析等

智能体的开发模式主要有四种。

1）平台

智能体应用是指拥有完整功能的软件应用，例如豆包。此外，华为、小艺、vivo、OPPO和荣耀等终端厂商也都有自己的智能体应用，并且开放平台，允许用户注册，并在此基础上创建子智能体。这些平台通常对开发要求较低，有许多现成的模型，有些无需付费，只需简单配置和拉通数据即可。

2）技术要求

理解智能体基本概念，无必要技术要求，甚至只需参照手册即可。华为智能体平台较复杂，可定义展现卡片。

3）优点

平台能力完善且成熟，开发成本低，能够快速落地试用，支持终端策略的迅速发布。

4）缺点

• 绑定平台，依赖平台大模型能力；

• 一旦进行数据迁移，数据安全问题会随之复杂化；

• 无法完全控制自有的数据；

• 使用场景具有局限性；

• 界面定制能力相对较弱。

1）平台

例如Coze，它是一个公有云的开发平台；发布成H5或者API接口（SSE）。

2）技术要求

需要一定的体系知识结合、软件知识和编码技能（AI可辅助，当前不是问题）。

3）优点

可自主选择各种大模型，并且工具资源完善，如联网搜索、天气查询以及图像和视频处理等。流程可自由编排，支持灵活构建知识库做RAG增强。

4）缺点

• 一旦绑定平台，开发者便完全依赖于平台提供的服务；

• 数据安全存在不可控因素，尤其对私域数据的处理效果可能不太理想；

• 成本较高，包括调用次数限制，需要购买会员以获得更高的调用次数和并发量。

1）平台

例如Dify；发布成H5或者API接口(SSE)。

2）技术要求

需要一定的知识体系、软件知识和编码技能（AI可辅助，当前不是问题）、部署和维护。

3）优点

• 快速落地；

• 流程自由编排；

• 大模型可选择私有化部署；

• 灵活构建知识库；

• 数据安全可保障。

4）缺点

• 功能完善度灵活性较差；

• 集群方案相对较弱，尤其应对大并发量场景；

• 工具和部署依赖自身的研发和运营部署团队。

1）平台

在技术框架的选择上，可以考虑Spring Ai，Langchain；milvus，faiss等。

2）技术方案

要求开发人员具备完整的技术知识体系、强大的架构设计和编码能力，自己部署和维护。

3）优点

• 随心所欲进行各种操作；

• 引入多智能体，使其自主执行多种任务。

4）缺点

开发成本高，算力、服务器、存储，都需要大量投入。

应对方案：

1）使用权威的知识库，保证信息准确；

2）设置信度阈值，优先采用置信度高的信息，敢于质疑并淘汰低置信度的信息；

3）使用参数量更高的模型。

①从实践经验来看，目前有通义千问7B、14B，以及DeepSeek蒸馏版本的7B、14B、32B 等模型可选。

• 建议尽量少换模型，32B作为基础版本；

• 7B可用于做简单的判别和文本总结，但需微调；

• 14B可承接稍复杂的任务，但不建议用于数值计算、复杂逻辑判断。

②在流程中做逻辑补全、补充常规知识。

• 这类知识并非让大模型自主学习，而是针对场景里常规易错的问题，提前梳理并植入提示词中，形成更好的判断与感知，让大模型能识别这类错误。

这在自主系统的智能体中是一个常见问题。

应对方案：

更好地规划思考、行动和观察的循环，并设置应用中断，以防止资源耗尽，避免无限循环。

应对方案：

以往写代码时，参数调用都是人工硬编码。但在智能体中，更多是由大模型自主判定：解决当前问题需要调用什么工具、工具参数来自上一步的哪里、该如何获取参数。因此工具的描述信息尤为重要，只有描述精准，才能让大模型理解并结合场景做好精细化分析。

对模型做微调是另一关键环节。通过微调模型以深入理解特定问题和场景，是解决API调用错误的有效途径。当前MCP受欢迎是因其相对有效解决了模型工具的描述和调用问题。

造成延迟的原因主要有两个：

1）上下文Token太大；

大模型输入Token越大，推理过程越耗时，消耗Token的数量也越多。

2）提供的知识库信息过多。

应对方案：

1）摘要或清楚历史对话，精简Prompt

为保障精确度，应先做摘要处理（包含核心要素、意图与对象），避免直接将所有历史对话或全文长篇内容提交给大模型。通过二级或三级RAG，最终筛选出与知识库强相关的精准信息。实际上是精简prompt，让大模型推理更高效，提升召回准确率。

2）对重复查询结果进行缓存。

3）不同的场景下使用不同参数量的模型

模型参数量越高，参与推理的算值越多，推理速度就越慢。因此，在不同的场景下，需要使用不同参数量的模型。虽然高参数量通常意味着更好的效果，但这也带来了高成本和高消耗。在某些场景中，无需进行复杂计算或推理，32B或14B的模型已足够使用，或者可以对简单问题和复杂问题分别采用低参数量和高参数量的模型。但如果是进行反思和规划，需使用高参数量模型。

应对方案：

1）清洗和拦截恶意用户指令

平台会收到用户对错误信息的投诉，甚至包含不应输出的错误内容。因此，需对拦截恶意内容，对知识库的内容进行检查和清洗。 

2）严格限制智能体可访问的API和数据

3）最终输出前接入安全API进行审核

对外输出的内容必须经过全面审核，确保准确无误。

由于智能体的答案是流式输出，因此多数场景下需要设置撤回功能。例如输出过程中出现不当内容，可撤回已输出的部分内容；也可在整段回答输出完毕后，执行整体撤回操作。

最佳实践总结：

1）从简单功能开始，逐步复杂化，快速试错。

例如，可以先使用一个大模型，添加知识库让其回答问题，随后做知识分解、意图拆解，进行二轮思考、行动和观察，以此推动模型持续演进。

2）记录完整“思维链”，是调试优化的黄金数据。

大模型存在不确定性，仅关注结果无法确定模型中具体哪个环节出现问题。记录完整的思维链才能发现并定位大模型的问题。

3）规划、工具、记忆等模块解耦，易于调试。

无论是代码编写还是流程编排，都需要明确的模块划分。例如意图识别、规划、任务拆解、工具封装、记忆等专属模块，并将这些模块作为子流程或子工具进行编排解耦。如此一来，进入完整的思维链时能快速定位到具体是哪个模块出现问题。

4）构建测试集，结合客观与主观评估，量化性能指标。

要快速实现优质效果，需在场景上搭建完整测试集，实现客观评估与主观评估，并基于用户问题做日常监控，提取出来做自动化评测评价进行打分，同时提取BadCase进行优化，并量化耗时、准确率等性能指标。

1）可观测平台的核心组件

可观测平台通常由数据采集（包括端侧数据、接口指标等）、存储、分析和可视化四大核心组件构成。数据采集负责收集系统运行数据，存储组件确保数据的安全性和可访问性，分析组件通过算法挖掘数据价值，可视化组件提供直观的数据展示。

2）在运维中的作用

帮助运维团队快速定位问题、提前预判风险、优化系统性能，同时为后续的扩容和保障提供知识和技术指标。

1）传统运维体系的局限性

依赖人工操作，效率低下且容易出错。随着系统复杂度的增加，传统方法难以满足快速变化的需求，亟需智能化解决方案。

2）智能化运维的需求与趋势

现阶段AI尚未具备人类级别的感知与高阶思维，但其在处理海量数据、从中提取规律的能力远超人类，并具有较强的泛化能力。通过提示词引导，人工智能能够自主发现规律并进行数据分析，尤其高参数模型在语义理解与逻辑关系的分析和梳理上表现突出。

智能化运维引入人工智能技术后，能够协助进行归因分析、监控分析和决策，还可以自动生成日报、周报，并创建可视化数据报表，为传统运维体系带来新的变革。

1）智能根因定位与关联分析

自动关联日志（需配套开发工具、设计提示词等工程化工作，同时要有反思和分析过程）、指标、追踪数据，通过拓扑图谱和AI算法进行归因分析，快速定位问题。

2）异常检测与预警预测

故障检测和提前预警是大模型所擅长的领域。此外，可针对日常的运维数据对模型做微调。微调的价值在于能够提升模型的分析准确度，减少幻觉现象。

3）自动化故障自愈

自动化故障自愈相当于构建一套工具供大模型调用。尽管大模型能完成此操作，但最终仍需要人工确认。另一种解决方案是多模型协同决策，但仍需要人工手动干预。

4）智能容量规划与成本优化

基于现有数据和工具调用指标，大模型可开展资源预测分析，给出精准的扩缩容建议与资源优化方案，在保障稳定性的同时降低云资源成本。

5）自然语言交互与智能问答

运维人员可通过整合运维体系内日常的FAQ、采集的数据等构建知识库，并将其封装为工具供大模型调用，实现支持自然语言交互的操作界面。通过界面做常规的数据分析和问答，提升信息获取效率。

6）安全可观测性与威胁响应

持续分析日志和网络流量，通过行为分析模型识别异常访问、恶意攻击等安全威胁，并自动触发安全编排与响应流程。

归根结底，智能体是基于高质量数据和自主调优或训练出适配的模型，根据设定的规划流程，让模型自主完成问题分析、任务分解、数据检索和决策工作。

1）智能体技术的未来发展方向

未来，智能体的发展仍将大模型作为基础。随着技术的发展，智能体强化学习和微调的难度逐渐降低，平台也普遍具备相关能力供技术人员自行探索和开发。

除了开发大模型的能力，演进是智能体技术发展的核心。例如智能体对图片、视频等的理解，推动其在多模态方向的演进。此外，随着大模型技术的进步，智能体整体也逐步实现自主化。

2）智能体技术对运维体系的深远影响

智能体技术对现有运维体系产生深远影响（例如AIOps），这种变革会提升运维的效率与质量，因此运维工作必须紧跟技术演进和变革的步伐。