没想到现在“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）,包括用户的行为特征、偏好、需求,使用不同的数据特征来理解用户,解决同一用户在不同场景下需要不同的服务方式需求,下图右半部分
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 urlwherethe A2A service can be reached.A2A Capabilities: Supported protocol featureslikestreamingorpushNotifications.Authentication: Required authentication schemes (e.g., "Bearer", "OAuth2")tointeractwiththe agent.Skills: A listofspecifictasksorfunctions the agent can perform (AgentSkill objects), including their id, name, description, inputModes, outputModes,andexamples.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，以及各种积分系统的处理，包括航空里程、酒店积分、信用卡积分等。这种状态化的设计使得整个系统具有良好的可追溯性和可控性
以航班预订过程为例，系统会进行毒性检查Toxicity确保推荐内容适当，通过偏见检测验证Bias/Fairness价格推荐无歧视，采用隐私保护措施Privacy脱敏处理敏感信息，提供可解释性说明Explainability推荐理由，并记录完整的决策过程Accountability以支持问责制
Epilogue 从最开始Gen AI,AI Chatbot,拖拉拽的Workflow,到单个的Ai Agent,现在开始研究发展更复杂的Multi Agent互动协作的Agentic AI,整体AI应用技术每年是稳定进步的,现在方向也越来越明确
joyce birkins
