企业构建Agentic AI应用当前4个难点和基础模块

没想到现在“Agent”这个词已经开始区分为 AI Agent 和 Agentic AI 两个概念了。我原本以为只是普通 agent 和 multi-agent 的区别，事实上也确实有这种理解方式，比如我在上一篇文章提到的，单线程的 agent 和需要协调多个 agent 的系统。

这篇文章分为两个部分：01 部分简单介绍这两个概念，以及目前实现上的一些难点；02 部分梳理一下现在企业在开发 Agent 产品时通常需要构建的模块,偏概念向

01

今年5月底有个标题叫AI Agents vs. Agentic AI: A Conceptual : Taxonomy, Applications and Challenges的论文发布,阐释AI Agent和Agentic AI的区别,其实就是Multi Agent多智能体系统挑战综述,Google A2A, Claude Code & Research, Gödel AgentCognition博客的单线程Ai Agent和Claude Research做的需要沟通协作的Multi Agent(Agentic AI)

过去的AI Agent已经能做出成果,完成单项任务,比如下面这些企业服务场景

第一个场景是客户支持与内部企业搜索，AI智能体通过连接CRM系统和API来处理客户的订单查询和员工的政策查询；比如AlpahSense 金融情报搜索摘要,Hebbia金融企业文档搜索,Glean通用企业搜索

第二个场景是邮件过滤与优先级排序，智能体能够自动识别高优先级邮件、检测任务内容并提供回复建议，同时结合用户偏好进行个性化处理

第三个场景是个性化内容推荐与基础数据报告，智能体可以根据用户的兴趣和行为模式推荐相关内容，同时生成各种数据分析报告

第四个场景是自主调度助手，当用户需要安排会议时，智能体能够自动查找可用时间段、协调各方日程并完成会议安排,比如Otter AI, Fireflies AI,Supernormal等

而现在想要实现更复杂的更自动化更智能深度的内容,除了LRM基础大模型继续想办法变得更聪明,开始详细开发可以协调编排、自适应理解拆分任务、透明可追溯、上下文共享记忆机制的Multi Agent,即右侧的Agentic AI

而这提到的4个问题是目前还在努力探索推进的,成熟度不高

所以近几月Agent类论文方向集中探索这些协调编排问题,比如让Agent生成任务更丰富深度的TaskCraft,以及一直以来强调安全和重点研究可解释性追溯的Anthropic,开源的MemOS记忆项目

上下文共享Cognition博客就有专门说明:

生产系统中的对话往往是多轮的，主代理可能为了拆解任务调用了多个工具、查阅了多个信息源，而这些“上下文细节”都会影响任务语义的解释。单纯copy传递初始任务描述是不够的,因此共享上下文，并传递完整的agent trace，而不仅是单条消息。

Agent不应只看到“你该做什么”，还应看到“上游是如何得出这个任务的”、“用了哪些信息源”、“做了哪些决策”。只有这样，才能保持整个智能体系统在执行路径上的一致性与可靠性

而最近我看到实际用代码尝试实现一个简单的旅行订票Agentic AI,其中作者尝试了Agent to Agent共享上下文都不行,得在上一步调用MCP tools就共享信息,这样Agent trace信息更多

以上是到现在这阶段Agentic AI的一些情况,下面介绍这阶段企业用Agentic的模块组件。各个组件偏抽象总结方向,每个完善的Agent AI项目都有这些方向的考虑,落实到工程代码现在Ai发展水平有些难实现,但是是以后必要的模块

02

这部分素材主要来自Agentic AI Lifecycle for Enterprise Processes的medium博客文章,medium版本有点故意拆碎了写的感觉,实际上是有个ppt版本的,推荐看ppt,我按照也是按照ppt版本的逻辑梳理

构建Agentic AI系统所需经历的六大关键阶段：

①定义使用场景（Scope）明确问题背景、业务目标、数据依赖，并量化ROI，作为Agent开发的起点。

②组件选择（Select）避免临时自建，改用标准化的LLM、Agent和工具市场。利用 Agent Card（A2A协议） 和 MCP协议 进行能力发现与结构化调用。

③代理设计（Design）区分确定性代理（静态流程）与自主代理（目标驱动、动态适应）。设计过程取决于任务复杂度与灵活性需求。

④治理与安全（Governance）包括访问控制、内容安全、失败恢复、人工介入机制等。没有治理，就不该进入生产系统。

⑤效果评估（Evaluate）通过LLM作为评审器（LLM-as-a-Judge）或人工评估，确保行为可控、目标达成。

⑥优化部署（Operate）包括量化模型以支持边缘设备，遵守合规要求，进行AgentOps运维。

相应的数据流程处理框架构想:

第一阶段是数据发现（Data Discovery）。当业务部门在Data Product Backlog中提出新的需求时，Data Research Agent 会主动搜索各类可用数据源。这些数据源包括数据库、文件系统、API接口等。代理不仅识别和评估潜在的数据资源，还判断哪些数据最有可能满足当前的业务目标，为后续的数据处理打下基础。

第二阶段是数据编目（Data Cataloging）。由 Data Lineage Agent 负责，它的任务是追踪每一个数据资产的来源、处理流程和最终用途。它会记录下数据从哪里来，经过了哪些转换处理，最终被用于什么场景。这种谱系信息对于数据治理来说非常关键，可以帮助企业更清晰地掌握数据的生命周期，也便于日后的审计和问题追踪。

第三阶段是数据处理（Data Processing）。由 Data Quality Agent 接管。它主要负责数据的摄取、建模、清洗、转换以及性能调优等工作。通过对数据进行质量检查，这个代理可以发现缺失值、重复数据、异常值等问题，并执行自动修复。最终目标是确保所有数据在进入分析流程之前都是准确、完整、一致的。

第四阶段是洞察生成（Insights Generation）。在这个环节中，Text2SQL Agent 发挥着桥梁的作用。它允许用户直接使用自然语言（例如中文）向系统提问，并自动将问题翻译成SQL查询语句，从数据库中提取答案。这样一来，即使是不懂SQL语法的业务人员，也能轻松获取数据洞察，极大地降低了使用门槛。

整个流程背后还有一套智能的数据治理体系在默默支撑。Data Governance 层贯穿数据生命周期的各个阶段，涵盖多个专门的治理代理。例如:

Process Understanding Agent 用于优化整体流程，Data Integration Agent 负责整合不同来源的数据，Metadata Validation Agent 确保元数据的准确性，而 Data Observability Agent 则持续监控数据质量和系统性能。此外，Performance Tuning Agent 会进行系统性能调优，Reports Generation Agent 自动生成各种业务报告，而 Caching Agent 则通过智能缓存策略提升整体效率

该博客文章还用一个企业客服Agent(Customer Service Desk)作为示例,阐释现在新一代Agentic需要考虑的模块

在传统架构中，用户通过聊天机器人（Chatbots）、邮件（Emails）或电话（IVR）提交请求，进入工单系统（Ticketing Platform）。之后这些请求通常会交由人工客服进行手动规划与判断，再依赖于CRM/ERP系统、AI模型或RPA等方式解决问题。这种结构最大的问题是：人工处理多, 信息流零散，用户互动层和处理层之间断裂严重,决策流程静态、固定，难以灵活适应复杂需求

Agentic AI 架构通过将用户交互、规划决策和工具调用整合为一体，实现了高度自动化的服务流程：

个性化与责任型AI层（Personalization & Responsible AI Layer）: 用户交互首先经过情感识别（Sentiment Analysis）、客户细分（Customer Segmentation）与安全约束（Safety Guardrails）

用户交互Agent（User Interaction Agents）包括基于RAG的客服Agent,自动生成邮件回复的语言模型,音频识别/语音助手

LLM推理规划（LLM Reasoning-based Planning & Decisioning）由LLM对请求进行理解、分配任务并调用后端工具

三类特定客服场景的Agent流程：

①Product Agent 关注的是用户买什么、怎么比较商品，确保他们找到最合适的产品；

②Customer Agent 关注的是客户怎么沟通、有何不满、需要什么情感或语言风格的回应；

③SLA Agent 则站在系统或服务提供者的一方，确保整个“服务流程”符合公司对外承诺的标准.比如每个客户的问题都在 规定时间内被回应（比如承诺1小时内响应）,如果超时或处理失败，它会自动 升级问题 或 通知负责人,分析历史数据，找出 服务瓶颈或绩效问题

工具库（Tools Library）：例如知识库检索、Web检索、Text2SQL、NLP摘要等

RLHF（Reinforcement Learning from Human Feedback） 在Agentic客服系统中的应用关键在于让LLM在交互和决策中更符合人类标准、客户预期,模型学习用户喜欢的回答风格，比如：简洁但覆盖全面,优先提供解决方案而非过多解释,保持礼貌且可信

Reference

Customer Service Desk在推理时的模块组成

用户首先输入任务，这些任务通常包含上下文信息与个人数据。系统在接收到任务后，首先会通过隐私保护与责任型AI Guardrails模块进行安全审查。这一过程确保输入内容不涉及敏感信息或越界请求，并符合合规与伦理要求(这个模块设计下面一小节的专门针对用户Personalization个性化模块,待会会说明),随后经过 LLM Agent OS处理:

LLM Agent OS由三个主要组成部分构成：Orchestration layers、Orchestration Engine与Memory Router模块

Orchestration layers根据任务类型，动态组合不同的AI Agents与工具资源，形成可执行的“Orchestration Schema”。 依托Agent Marketplace进行功能扩展，支持如RAG知识检索、邮件生成、语音交互、客户服务、产品管理、SLA合规等多种智能代理。这些Agent可按需被编排调用，协同完成复杂任务

Orchestration Engine兼顾Orchestration Schema 和Integration layers, 负责AI与外部系统（如CRM、ERP以及tool marketplace各个工具）以及人类操作员之间的协调沟通,在必要时引入人工干预。

Integration Layer负责人类（Human-in-the-loop）,Agent to Agent APIs之间互操作,以及有人类操作参与的Agent to Agent with human in the loop

Memory Router则统一调度短期与长期记忆，实现对任务上下文的追踪、历史信息的提取与内容连续性控制

最后，任务被传入响应个性化模块，对即将输出的结果进行微调。该模块基于用户的偏好、历史行为、语气风格等因素调整输出内容，从而提升用户体验，使AI的回答更贴近用户预期

Personalization

Customer Service Desk Personalization自适应个性化需要的模块

Personalization Layer利用用户数据嵌入（User data embeddings）,存储用户偏好和交互历史,为每个Agent创建不同的用户画像（User Personas）,包括用户的行为特征、偏好、需求,使用不同的数据特征来理解用户,解决同一用户在不同场景下需要不同的服务方式需求,下图右半部分

针对Personalization个性化场景的多个Agent也有特殊之处,上图黄色Agent模块

LLM Agent OS负责理解用户输入，提取关键信息; Predictive Analytics Agent基于历史数据预测用户需求 ;Reinforcement Learning Agent选择最优响应策略;最后LLM Agent OS生成个性化回复

Responsibility

当用户提出复杂请求时，比如"预订经济舱机票到檀香山，在洛杉矶停留2天，使用首选航空公司X和Y，以及酒店连锁店"，系统会通过Orchestra Layer将这个复杂任务Task Decomposition分解给不同的专业Agent,根据该任务搭建新的Agent团队Agent Composition,其实就是FlowReasoner(查询导向Query-Level),根据每个具体查询实时生成一个全新的、定制化的Agent系统

下图是Agent to Agent要求每个Agent需要带上的描述

Identity: name, description, provider information.
Service Endpoint: The url where the A2A service can be reached.
A2A Capabilities: Supported protocol features like streaming or pushNotifications.
Authentication: Required authentication schemes (e.g., "Bearer", "OAuth2") to interact with the agent.
Skills: A list of specific tasks or functions the agent can perform (AgentSkill objects), including their id, name, description, inputModes, outputModes, and examples.

Travel Planner Agent负责总体行程规划，Flight Booking Agent处理航班预订，Hotel Booking Agent负责酒店预订，Transportation Booking Agent处理交通预订，Activities Planner Agent安排活动。这种分工确保每个Agent都能专注于自己的专业领域，提高整体服务质量

图中最特别的是状态化执行流程树形图，这个网络结构展示了Agent间的协作过程。整个执行过程是状态化的，每个节点代表一个特定的执行状态，虚线表示条件分支，实线表示确定流程

每个执行状态是符合Ai Guardrails的

“AI Guardrail（AI 护栏）” 是指在 AI 系统，尤其是大型语言模型（LLMs）或自主代理（Agents）中，为限制其行为边界、确保其输出安全、合规和可靠而设计的一套技术机制与策略。它像“护栏”一样，防止AI“越轨”或产生不当结果

从Trip Booking Trip Agent开始，流程可能涉及Flight Booking、支付处理、Hotel Booking，以及各种积分系统的处理，包括航空里程、酒店积分、信用卡积分等。这种状态化的设计使得整个系统具有良好的可追溯性和可控性

复杂的多Agent协作中，每个状态转换都需要通过responsible AI检查点。最右边灰色的就是相应的检查标准:

以航班预订过程为例，系统会进行毒性检查Toxicity确保推荐内容适当，通过偏见检测验证Bias/Fairness价格推荐无歧视，采用隐私保护措施Privacy脱敏处理敏感信息，提供可解释性说明Explainability推荐理由，并记录完整的决策过程Accountability以支持问责制

Epilogue

从最开始Gen AI,AI Chatbot,拖拉拽的Workflow,到单个的Ai Agent,现在开始研究发展更复杂的Multi Agent互动协作的Agentic AI,整体AI应用技术每年是稳定进步的,现在方向也越来越明确

joyce birkins