我想，这应该会是我最后一次较为完整的聊Agent的平台总体设计。为什么？因为感觉拼图已全。以后也不大会再有大的模块变化，有的只会是某模块的能力升级、效果提升，又或者是进一步的细分了。
建设平台体系的意义么，其实也未必要完整建设。重点还是从顶层设计的视角先整体和全面的看，再根据自己的场景特性以及偏好，找到自己的重心和切入路径。但是，有一点，是相通的，就是深度结合自己的业态。因为AI是增益性魔法，而不是创造性魔法，只放量不创造。结合业务本身的AI，就是对营收和利润的放量；结合用户体验的AI，就是降低用户使用专业能力的门槛，事实上，我们从不缺专业能力，只是普适性不高。
于ToB，如何将AI深度融入自身业务，是重中之重。是在深刻理解自身业务后的重塑业务流程、盘活业务活动和能力。因为自己最知道，自己的业务堵点在哪里，缺了什么。所以企业级的RAG知识库建设、对应业务活动的高码智能体建设，这些就更优先。一个积累企业内部的隐性知识，加强企业内部的跨组织协同；另一个则是将业务活动的工具化和专业化，增强业务活动的可靠性。只有业务活动可靠、稳定了，向上构建的业务流程才更有意义和清晰，各组织间的权责才分明、协同更流畅。所以智能体的快速开发和效果评价、数据权限隔离、稳定运行的生产级智能体运行服务，尤其重要。
于ToC，如何将用户使用的门槛降下去，才是最优先的。“我不想知道原理，也不想学习，只要正确的结果方便直观的摆到我面前”这才是C端用户最想要的，当然，至少我是这样的。因为个人的场景里，不需要与人协同，自然不涉及组织和流程，只要关注输入和输出。看看如火如荼的AI Coding，众人追随的Claude Code，就可见一斑了，还有各种报告文档生成、PPT生成，有几人真正关心原理和过程。所以，AI门户的建设，如何让用户更好的发现AI能为我做什么，是更重要的。沙箱也很重要，因为它让用户更敢于try。
于实验性质的场景，更是专精到了极致的一个点上“我能同时并行开启多少种模拟尝试”。可方便运维的，具备大量算力资源的MaaS层建设，很关键。
注意，我说的是建设过程中的侧重点和切入点，而不是只建设一部分。其他的，不那么关注的，可以少投入、弱建设，但他们都是客观存在的。
所以，我们还是先来看看完整的功能视图，此处仅以B端视角来展开了：
让我们一层层的往下看
SaaS层
其实从企业应用场景支撑的视角看，重点只看要对齐业务架构，想清楚对业态和组织产生了什么价值，那么就找到了场景的突破口。如果只是换一项技术或技艺重新把事情干一遍，那只是重复劳动+1而已，解决方案层面的版本+1，看着热闹。
那么究竟什么是业务架构，其实就是定义出**“做正确的事”，再指引诸位用技术和工具“正确的做事”**。
具体呢？是什么，包含什么？
还是太抽象？那举个例子，就以银行的对公开户为例吧。
你会很容易的发现，所有的技术和工具都是在业务设计的指引下，找到最适合的，来排列组合完成业务落地，关键是业务设计先行。
对企业来说，最重要的就是业务设计，先想清楚价值流向，回答**“我做这些事情是怎么样一步步推导出我的收益的”，才有继续往下拆解业务流程和业务活动的必要性。才有“选什么技术和工具，才能做得更好”** 的意义。要么，是平替了某个业务活动，比原来做得更好；要么，是提升了业务流转的流畅度和体验。
举个例子，以前的线上预约，有太多的内容信息要填写，作为普通人，我可能不是很理解这些内容，于是操作的时候，不是很流畅，我也不是很满意。现在呢，交互方式改成了对话式交互，我发现聊天我会啊，还很轻松。然后，在我需要上传资料的时候，AI又能帮我找到合适的证件资料上传（当然，这是需要我授权的），我又会觉得，很不错。那么，这就是一个能实际提升业务效果的替换，值得做。因为终端用户的体感好了，对为用户提供服务的企业的亲合度也自然会好，对企业就是产生了收益。
业务设计要怎么做？
其实挺容易的，就是要花心思、花精力，真的做。过场式的干，没什么意义。因为做出来的设计，并不解决问题和产生效果。而且，就算是真正花了心思去做的设计，在执行落地时，遇到组织壁垒和障碍，也有可能走歪走坏，使得效果大大折扣。所以，不花心思，就真没必要去搞。
传统的业务设计，定义的是人与系统协作来完成业务活动和业务流程流转。而现如今，则是人、智能体、系统三者协同来完成的业务。那么，自然的会发生职责职能的变化与转移，也会出现新的交互范式。
我们总说，应该把智能体当成人来定义，那么，我们就先把智能体当成人，代入到传统的业务流程中去，先替换掉部分人的业务活动。而智能体毕竟还是系统，所以可以改变人与系统的交互方式，转变成系统与系统的交互方式，甚至内嵌到一起，变成一个新的合体。
然后，逐步追求量变到质变。因为只有先在单一的业务活动让用户感知到了业务效果的提升，大家从有动力和热情去寻求下一个业务活动的改善。只有由点到线、由线到面的打透，才有质变的爆发。否则，依旧是那么不起眼的微创，就和前些年的小模型一样。
PaaS层
平台设计的关键点所在，就得先从平台的整体定位来看，也就是放回到整个架构中去，找到它的位置。
平台输入的是原本就存在于原架构中的系统能力（包括API、表单等）和业务化加工处理的数据，输出的是更贴合场景、更灵活的智能体。
为什么我是这个观点？我请问，现在还会有从无到有的完整系统建设么？我的答案是，没有。谁不是背着原有的旧系统包袱，在前行。谁家没有几个旧系统，已经是只能运转、不好维护了。谁家的土财主会说，推倒，重来。那么中间的真空期，我们的业务该如何持续运转呢。所以，一个更好的路径，自然是把原有的系统能力，尽可能的用起来先。先把我们预期的业务效果拿出来，先证明新的模式切实可行、比原来好，再逐步迭代，修里子。数据，也是同理。原先的架构和体系里，不是没有数据，相反的，运行的越久的系统里，越是有大量的宝贵数据。只是，当初他们被定义的太过于技术化，许多业务部门的人，特别是后来者的业务部门人员，不是能很好的理解它们，自然也就不能发挥数据的作用，所以如何能结合企业内的“业务术语”、“业务代词”，让它们被理解，再结合外部的主流“术语体系”让它们被激活，才是重要的。
我们来看下智能体的构成，按照智能体的处理流程来切分，大致可以分成以下几段任务处理流程：
输入感知
这里实则是在完成了信息输入的基础上，多主动做了一步感知，而且是专门针对用户的，如果调用方是系统，则不需要，因为系统之间向来是遵循严谨的接口约定的。而我们对用户的输入，则需要充分考虑到体验的友好，让用户懒惰。我们宁可对口语化的文本输入增强语义理解，而不是要求用户按照系统的规则来格式化输入；宁可让用户进行语音输入，不断提升ASR的算法和电脑音频采集的硬件质量，而不是让用户只能打字输入；通过GUI用户偏好记录的方式，来记住用户习惯，不断提升**“猜你想要”** 的命中率。因为方便用户的交互设计，才是能留住用户的设计。否则，你将失去很大一部分普通人用户。好的感知系统设计，是能帮助用户越用越顺手的，而不是每次进入都要经历一轮初始化。就好比是越高超技艺的外科医生，越喜欢能精准配合到他的那位给他传递手术刀的护士一样。具体怎么实现感知系统，这里先不做过多阐述了。核心就是，数据为王，再辅一部分的行为心理学的常识。初始启动的时候，不用过度设计，因为你未必真的理解用户的操作意图。
意图拆解
为什么是意图拆解，而不是意图识别？因为普通人在使用的时候，问题越是不受规则约束，就会越发散，逻辑性也未必那么严谨，还通常会包含几个隐含问题在一个问题里。所以这里其实是一个漏斗式的处理流程，先对原始问题进行改写，保证语句上没有基本的语法问题或者错别字；再进行问题拆解，保证每个问题尽可能的原子化，且不存在交叉；然后，才是意图识别，说是识别，事实上是把问题输入和系统能力进行勾兑的过程，没有能力匹配的意图，并没有多少被正确识别的意义；最后，则是要素提取，因为一旦意图被识别，就说明找到了系统的功能，就有了明确的接口输入，从原文中提取明确的接口字段，提取不到则交给用户进行输入，这已经是技术人员门熟知的部分了。
任务规划与执行
这部分，是我认为的智能体最核心的处理流，也是我最喜欢的部分。任务执行顺序的规划分为Agentic AI的自主规划模式和Workflow的工作流模式，实际上就是工作流程的实时规划还是预设预编排的差异。前者，具备足够的数据灵活性和场景精细化，也有大力出奇迹的味道，所谓“人不能穷举或概括的场景，交给AI”；后者，需要比较强的行业至少是相关业务的专业经验，才能尽可能的考虑完善，覆盖绝大部分的场景，而且尽可能的内聚。
我偏好是会把L2和L3层级的流程交给自主规划模式，更具体的说是ReWoo的方式来产生任务的执行流程，再交给事件执行器来稳定的执行过程事件，此时每一个L4层级的流程会被定义为一个事件。为什么这么选的理由，其实以前也提到过，越是上层的流程，越是接近业务设计，也越是需要业务部门的参与和设计，而大多数的业务部门的同事的主要技能点并不包含技术，所以很多执行顺序、输入输出之类的问题他们并没有那么强的约束。以往，经常是架不住技术团队的要求才强行概括的。事实却是，有很多场景上，存在实际的细小分支逻辑和操作被扔到了系统外，交给了人工主观判定。
进入了L4和L5层级的流程后，则是ReAct方式和Workflow方式都可。对执行顺序和执行效果要求都很严谨的，选择Workflow方式更舒适，因为稳定、可控。其他的，就可选择ReAct方式，因为它显得更智能，是的，更多的只是这个理由。毕竟ReAct的核心设计就是在于loop，这也是为什么此处有被提出和沙箱Sandbox的原因之一吧。毕竟不断的loop尝试最好是现在一个模拟环境里证明了执行结果的可用性，才去正式环境里运行，是个更安全的选择。追一句，到了L5层级，如果还不能找到原有系统里的完整可执行的函数调用链，属实有些不好想象。但若是在这一层继续进行loop，我只能说，我也蛮喜欢偷懒的。
我的核心观点是，自主规划模式的作用是让AI帮我们快速试错的锁定到切实可用、好用的业务流程，我们真正想要的，其实还是稳定运行的Workflow，只是区别了需要依赖业务经验总结的Workflow。省下了这里大量的业务思考和决策难点，有个相似的例子，就好比早些年电商平台做用户画像时一样，从早期的研究用户心理的经验主义，快速跳到了“我只看最后操作”的数据驱动和数据分析。比起挑选万中无一的业务专家，大量获取用户数据总是更直接和简单。
值得注意的是，Agentic AI的自主任务规划，是必定要匹配一个充当观察者身份的数据洞察引擎的，需要准实时的收集数据，根据预设的业务指标和技术指标对任务规划的准确率进行打分和评价，以确保任务规划的准确率是落在我们可接受的数据范围内的，而不至于离谱；以及在万一离谱时，能具备实时打断干预的操作，避免越偏越远。
后处理输出
又是一个十分重要的环节，或许你会觉得，经过前面的意图拆解、任务执行与规划，你已经基本实现了，而且有了相当的执行效果，只要简单的把结果输出出去，就万事大吉了。现实是，如果输出的内容过于技术化、缺少整理归纳，或许是不便于用户阅读和理解的。就像是人与人之间的沟通一样，你对某个事物的理解虽然很深很正确，但如果你的表达不是很利于听的人的习惯，那么有可能的结果是，并没有达成有效沟通的结果，对方完全不能理解你传递的内容，甚至觉得那不是正确的内容。你看，即使是一个业务或技术的专家，都有可能触发这样的尴尬，更何况是大模型、是智能体，因为他们更多的时候是基于人类专家告诉他们的内容来进行的内容传递。所以，当然的，得专项训练他们以用户能理解的方式来进行内容输出。
所以，需要对智能体执行的输出进行专门的归纳总结，再进行一致性检查确保他们没有被变成其他的含义，当然结果也得是安全、向善的表达方式，最后再转成更直观、更具备可读性的方式进行输出。LUI，就是这最后一道工序，它能把结果输出展示成我们更希望的UI形态，方便我们去查看和理解。
于是，说到这里，平台层需要重点建设的部分也就清晰了，按照层的不同，可以先拆成应用中心和能力中心两部分。
在能力中心，关键的是智能体运行服务、大模型IQ管理和工具集合。在应用中心，唯一重要的其实只有AI门户。而其余的，则都是为了让平台运转的更好的管理配套、运行基建和运维工具。如果你不是为了售卖平台本身，其实真没必要花很多精力在这些点上。毕竟你必然的会有一支技术团队，他们会搞定这些内容。比如用配置文件和sql脚本搞定参数化配置，用开源的技术工具搭起基建和运维工具，甚至有时候都可以省略运维工具而保留几个熟练运维工作的人。
先看能力中心，逐个展开：
智能体运行服务
分为两个部分：智能体运行引擎和多智能体协同服务。
智能体运行引擎：主要用于实现单个智能体的完整步骤执行，将每个过程步骤进行事件化设计，基于事件驱动的模式进行实现。
这里，核心做好两件事情就可：整体处理流的管道设计和事件对象设计。以事件为核心抽象层对象，将处理步骤进行动作化和事件化。好处是，只要进行一次的处理流程设计，就可完全盖住后续的逻辑变化。事件对象设计，是个值得玩味的地方，对象的传递和热点数据的识别。
多智能体协同服务：主要用于实现跨智能体的协同和调度，以及实现智能体与同层的传统应用系统间的通信与状态同步。协议嘛，自不必说，当然选A2A协议了。此处不想赘述为什么不用Mcp协议，注意前面特意强调了与同层的传统应用进行通信。
大模型IQ管理
其实，我内心也是一直很纠结这部分的模块命名，原因就是叫知识管理，感觉只包含了RAG部分，而且更容易偏向针对知识的一系列管理功能的搭建；叫记忆管理，又觉得没有体现出对知识工程的理解和知识的沉淀积累。二者缺一不可，就和人一样，并不是所有有用的讯息都存储在脑中，相当一部分只是记了个索引，便于想要时可以快速从电脑里找到对应的文档，又或者是从方便找到的地方拿起那本有用的书。
所幸，微软的Azure AI Foundry平台就比较聪明，命名成Foundry IQ，似乎就巧妙的盖住了这两块内容。所以，我们也就称其为大模型IQ管理吧。
记忆体服务：是面向 AI 智能体（Agent）的托管式记忆基础服务，核心是提供短期上下文 + 长期结构化记忆的统一存储、自动提取、语义检索与隔离管理，解决多轮对话遗忘、跨会话断档与上下文衰减问题，让智能体“更懂我”和具备“灵性”。
RAG检索服务：是面向大模型的托管式外部知识检索服务，核心是提供私有 / 实时知识库的精准检索 + 上下文增强能力，解决大模型知识截止、幻觉、专业知识不足三大痛点，是AI落地企业场景的核心基础服务。
记忆，是智能体直接使用的部分。记忆体是记忆的载体，没有记忆体的配合，智能体只是一个逻辑性很强的推理机和处理器。知识，则是对记忆中的高质量内容，复杂内容的展开则是存储在知识库中。类比到人来说，所谓记忆一定是我认为重要的内容，但未必是知识，只是我认为我需要记住的；而知识，是符合主流认知并被认证为正确的重要内容，但未必是我认为重要的，否则我怎么会不知道或记不住。这也是为什么我会认为记忆体才是智能体直接使用的模块，是不可或缺的；而知识库却是一个有就行的存在。就好比，我并不喜欢做菜，甚至几乎不进厨房，所以烹饪相关的知识对我就是不重要的，可能一辈子都用不了几次，我当然不需要掌握，学了也没用。
具体的记忆体设计，这里也就不再展开了，在去年的记忆专题里，我就描述过。在这里，只是想再次区分和定义下智能体、记忆体、知识库三者的关联。然后，再强调下，记忆的评分卡模型设计的重要性，以及会话信息抽取、记忆更新、记忆巩固、记忆遗忘、知识主动学习这几处的过滤器设计的重要性。记忆的存储和缓存，只是为了在数据量足够大时，让检索的效率依然能落在舒适区。
工具集合Toolkit
如果说前面提到的模块，是提供了由点到线的连接能力，那么工具集合里装着的，就是各个点的能力和配套。
网关服务：顾名思义，其实就是软件层面的路由器。这里又按照通信链路上的位置不同，进行了拆分：接入网关，负责面向智能体的请求接入转发；AI网关，负责智能体向工具能力的请求调用转发。
大家对家里的路由器怎么用的，基本上，对网关服务也是怎么用的。只要应用服务的节点多了，就必然会存在的基建型服务。Higress，就的确很值得使用。当然，也有别的一些，如果有技术团队不服并且有持续研发的动力，直接上gateway、Nginx进行定开加装，也不失为一个好选择。
重要的是，带有业务特征的流控策略制定，积累有意义的插件。而且，是平衡了业务和技术的诉求之后的策略。业务，并不那么关注系统的运行开销，更多的还是业务上的分流策略，也就不免的将很多业务规则叠加进来。技术，则并不想在这个环节上，掺杂太多的业务逻辑，显然的会过度增加技术复杂度。
Mcp服务：按照Mcp协议把数据资源、工具能力进行标准化封装后，进行统一接口输出的服务。
-
Resources（资源）：只读数据（文件、数据库表、RAG 知识库、实时 API 结果）。
-
Tools（工具）：可执行函数（查 DB、发邮件、调用 API、浏览器点击、代码执行）。
-
Prompts（提示模板）：预定义工作流（写周报、生成工单、RAG 检索模板）。
其实多数情况下，这里需要积累的是企业内已有的具备业务属性的API能力，也就是我提到过的业务API，比如高净值的客户清单；而非天气查询、计算器这样的通用API。当然，通用工具能力在堆积工具个数的时候，展现工具池深度来进行方案营销时，还是具备充数的作用的。其中，我只认为两个通用能力除外，就是意图识别和归纳总结，原因其实之前分析智能体构成时，也已经点明了。
值得注意的是，Mcp协议本身只是定义了智能体在使用工具时的交互协议，对工具内的逻辑实现其实并没有很多的涉及。而Skills，则是专项的在这一层进行了丰富协议和规范。目的，就是让工具实现被定义的更简洁和有框架。
此处，再次强调我的观点，Skills是给智能体使用的，而非人，少拿人的使用偏好来规整Skills。同时，想到了一个有趣的问题：人，是怎么掌握技能的，掌握了的技能，最后都去了哪儿。
超级智能体:其实就是效果很优的、可解决复杂场景的、全链路、端到端、可自主闭环的高阶智能系统，前面介绍的智能体构成就是一个标准化的超级智能体的设计。
为什么在工具集里，会有它。因为OpenClaw、Hermes这些都的确已经做得很好了，至少大家都是这么认为的，并且还开源了。能直接用，为何不用。和前面提到的智能体运行引擎是否有一定的冲突，自然是有。我说过我的观点，智能体运行引擎的核心是稳定的运行事件流处理，在处理不同层的流程时，需要选择不同的处理模型。再者，OpenClaw、Hermes都可能是昙花一现的存在，而我所需要的智能体运行引擎是要深深的扎根在企业内部，和业务紧密的联系在一起，它更需要稳定和适应企业的土壤。
KV缓存服务：多数时候，都是被认为是大模型推理的“显存加速器和上下文记忆池”。
其实站在整个平台的视角，我会觉得，它可以管得更宽一些。针对整个智能体处理流程中的各个环节，进行能缓存则缓存，提高运行效率，拿空间换时间。大模型的推理的缓存化实现被强调，属实是因为模型推理时间太长，再有就是token贵啊。但其他环节，问题也是一样的，只是优先解决最痛的点而已。
从分层的角度来看，智能体侧的KV缓存实则是更偏应用层设计，隶属于PaaS层；模型侧的KV缓存是辅助推理优化的作用，隶属于MaaS层。
从关注点的角度来看，就是重点研究K的设计，而且是和业务有一定关联度的K设计。通用型的K，就先不假思索的缓存上吧，毕竟总体策略本就是以牺牲空间为代价的。而且还是得建立起K之间的关系拓扑，用于快速关联问题和定位到K。
算力调度服务：负责统一管理、按需分配、动态调度、弹性扩缩、优化成本、保障 SLA所有算力资源（GPU/CPU/内存/显存/网络/存储）。
核心定义好管理的颗粒度，即可。确认了管理的深度，也就确定下了有多少管理的策略可用。读过德鲁克的书并且有一定理解的人，大体都是有体会的。这首先不是一个技术问题而是一个管理问题，解决完了管理问题，技术上就是按部就班的执行。而且，本身这个模块的定位也是MaaS层的功能构建，这里也不再多的展开。
模型优化服务：其实就是模型微调工具服务，是面向大模型提供托管式、低代码、全流程的专属模型定制服务；不用懂深度学习算法、不用搭集群，就能把通用大模型，改成适配自家业务、专属风格、私有知识、特定任务的定制模型，是介于通用原生大模型和RAG 外挂知识之间的核心 AI 基础设施服务。
但说实话，这里的低代码化和全流程覆盖，意义真不大，但凡有能力做微调的人，敲命令写脚本的流畅度远高于用配置界面点选。这样的人，确实可能不是很懂复杂算法的原理和底层，但一定有很强的数感，也属实没必要浪费精力去解决集群、部署、这些工程类问题，专注于提升模型效果，就很好了。
知识工程服务：就是帮客户把散落在各个业务环节的数据、文档、专家经验，系统地变成可检索、可推理、可复用的知识资产，并提供配套工具与应用能力。
服务定义、核心流程，看着眼熟么？当然，毕竟知识本就是数据的一个子集，数据挖掘与治理的范畴。所以，能不能用原来的数据治理工程来实现知识工程，大体就是可以的。只是他对业务部门用户的友好度，对专项知识的描述方式友好度，可能过于技术工具化。真正值得思考的是，为什么提了那么多年的数据工程，做得并没有那么好，如果是这样，换了新名字的知识工程，又为什么能做得好。
知识获取，建议是多考虑做旁路数据的模式，少折腾现有的系统架构，没有走通知识工程和产生效果前，别一上来就各种系统对接式的采集数据。
知识表示，建议是先考虑收集业务团队内的“方言”、“黑话”，而不是用光鲜好看的专业术语。真正的用户，不能立刻接收和使用的知识，并不能产生价值。
知识推理，建议是少追时新的算法了，现有主流的算法和策略，早就已经理论过剩了。真正的用户在使用过程中，对于结果是不是他想要的，是最清楚的，多关注这些结果收集。用最硬的方式编码，达成了知识被命中的效果，又如何，只要是正确的。只要有足够体量的用户和使用量，算法和优化总是能被总结出来的，不用急于一时。
知识应用，建议是适当的找几个有价值的场景，不多不少最适合。也别再一上来就是智能客服了，感觉AI时代最典的场景就是客服场景了，遇事不决就客服的味道。客服场景，其实需要的是知识么，并不，他们需要的是降低用户的爆炸程度，用户如果满意就不会找客服了。所以，客服需要的是平息用户爆炸的手段。说一万句“亲，别生气，问题正在处理中”，不如一句“已退款，另有三张折扣券已到账”。知识，是辅助企业内部的，是帮助基层新员工快速上手企业内的各项工作的，不对外。管理层，其实并不需要，如果他需要，那么就应该联系HR快速将其劝退了。
数据洞察服务：是围绕整个智能体平台生态，针对智能体运行过程中涉及的业务关联数据、运行链路数据、工具输入输出等，通过清洗建模、统计分析、挖掘规律、归因拆解、趋势预判等手段，从零散原始数据里挖出智能体在服务业务场景的过程中存在的问题、潜在风险隐患、优化路径，给指引智能体更好的服务业务场景提供可落地的决策依据的专业工具服务。
智能体没有真正深入业务体系前，没必要专门建设，建起来了，也只能是一个长得挺好看的数据监控大屏和数据报告生成器，因为没有真实有意义的数据，哪怕是原始数据。
安全护栏服务：是面向大模型智能体（AI Agent）/ 多智能体系统的全链路安全合规管控服务，在智能体的输入→推理→工具调用→输出→数据流转全环节，构建策略化、可配置、可审计、可干预的安全边界，防止智能体越权、作恶、泄密、被劫持、幻觉误导，确保行为合规、可控、可追溯，是企业级智能体落地的安全底座。
安全防护要怎么做，其实是个已有的旧话题，只是模型和智能体这些对象是新增的，就连带的引入了一系列新的安全防护的关注点和策略。但本质核心关注点，还是不变：敏感词过滤、内容防篡改和越权操作拦截。
具体实践的过程中，是可以分步骤实现的，不用一上来就建设一整套完整的安全防护，直接可以干预业务执行。可以先轻量的接入，从运行日志入手，先获取有用的运行日志，进行现象级的分析，找到安全隐患的点。再进行逐项的分析，是否建设干预执行的防护。而且，事实上，让开发人员多输出几行包含你想要的有用信息日志，远比折腾什么探针技术、新增数据接口对接要便捷得多。一个看似完整但防护的位置未必对的安全防护服务建设，远不如日志分析，来得实用。
再看应用中心，逐项展开：
整体来说，属于直接面向用户的操作层。重要的，是定义出用户画像，回答“谁来用”。但凡用户接触层的设计，只有用户画像识别正确了，设计出对味的交互设计；交互设计对了，才能把功能设计做对。还是回归到平台的关键对象来看，操作中心的用户，是智能体的使用者，管理中心的用户，是智能体的运营者。
AI操作中心
面向智能体使用者的操作端，以对话式交互为核心交互方式的与AI进行协同的操作类系统，一切设计都只围绕用户如何能更方便的了解、掌握和使用AI。
设计风格上，我愿称之为“在B端系统里的C端系统设计”。因为，我们并不想再要阅读完长长的用户使用说明，再开始小心翼翼的使用系统，那是上个世纪的习惯。我们需要的是能让我们更得心应手和高效的协同习惯，最好的证明就是对话式的交互设计。
相较于原来的交互设计，核心就是从人与系统的两者关系转变成了人、智能体与系统的三者关系。系统，是提供服务的一方，是被动接收指令来做出响应的一方；人，却总是希望对方能更主动，这就和人与人的相处是一个道理。所以，智能体的加入，能让交互变得更舒适，就是一个必然，也没有改变人与系统各种原本的角色和定位。仔细一想，为什么人的历史中，总是在不断重复上演的：人一旦身居高位，就会想要身边多出各种助理、管家、仆人。未居高位者，内心也是有着许多憧憬的。想到这里，也就豁然开朗了，人之本性，这就是我们常说的用户的真实需求。
对话交互：操作中心的核心功能，将所有操作智能体的交互设计统合成对话式，以最原生的交互方式来完成人与智能体的交互。
在这里，我的观点是给出两类智能体操作方式：办公模式和探索模式。
办公模式，是企业内部由上之下定义的业务流程/业务活动，也可认为是传统业务的AI化工作流程转型，其原本的业务传递的约束并不会发生改变。
白话：老系统里业务原先怎么办的，现在还是怎么办，只是替换了处理步骤里的部分业务活动，让业务流转更智能了而已。至少设计意图，是这样的。
探索模式，是企业内部原本就没有定义在原有系统里的业务流程/业务活动，按照用户的操作场景和需求，交给AI可进行自主规划的工作流程。
至少，我一直是坚定的认为：
1、传统的系统建设，并没有真正将所有的业务活动进行系统化，依然有大量的业务活动是游离在主系统外的，或许是纯手工操作，或许是依赖各种个人小工具。
2、之所以这些业务活动，没有被约束进系统，自然也是有他们的缘由的，或许是抓大放小，或许是觉得不太好约束。
探索模式的好处是，可以在系统运转可接受的范围内，充分发挥群体智慧、激活原有的业务工具能力，可以尽可能的收集流传在企业内部的隐性知识，而不是仅依赖少数资深业务专家。让需求产生井喷，相较于去要求人专项提需求和挖掘需求，让需求自然的产生，显然会更流畅，需求也来得更真实。
计划任务：一系列由用户自主定义的定时操作智能体的自动触发式任务。其功效，和探索模式其实很类似。这里也不再赘述。
个人偏好：我给它的定义，是大模型IQ管理的个人版设定。智能体需要面向个人的记住用户的偏好习惯、方言、UI偏好，哪怕是常用的错别字的纠偏，并非完全都是有用的知识。先记住这些设定，再说是否要改进某些不是很好的习惯，别直接对着干。
智能体推荐：类似一个智能体榜单和推广的功能。说实话，这样的功能，从实用性角度来说，是可有可无的，我的偏好里就是只拿来充满页面构图，让首页显得不那么单薄而已。顺道给用户一个类似摸鱼小工具的作用，就和大家刷抖音、小红书一样，很多时候是为了刷而刷，打发下时间。
AI操作中心自身的智能化，主要体现在三个功能点设计：智能导航、GUI智能体辅助和生成式UI。
智能导航：本质上是意图识别的应用之一，缩短的是用户操作的路径。从传统的找工具入口->输入用户问题->获取内容输出反馈，缩短成了输入用户问题->获取内容输出反馈。因为给工具取名字这事儿，本就很难。很少有能取出一看名字，就能让初入门的新人能立马理解工具作用的，除了已经被广泛熏陶的那些平台基础功能以外，也就是我常说的是个系统就有的无聊功能。
所以，导航的智能化设计，只要核心解决：用户意图和功能入口的正确勾兑、让这个过程足够的快，就够了。具体要怎么做？也只要做好两条：
1、建设好用户问题与功能入口的正确勾兑关系。顺着用户来，不要去教育用户该怎么问。而是积累数据关系，做收敛。记住，做一个懂我用户的系统，而不是教育和约束用户的系统。如果觉得数据关系放在模型外，技术上的兴致不高，那么就在达到一定数据体量时，训练到模型里去。
2、用好缓存技术，设计好缓存KV，不要每一次导航都走推理，自然就快了。优化推理算法？技术人的乐趣所在罢了，总是追求用最少的代码，更快的解决问题。这个目标没错，前提是你先解决了问题。
GUI智能体：能像人一样看懂并操作手机 / 电脑界面的 AI 助手：接收自然语言指令，通过屏幕截图理解界面，自主点击、输入、滑动，完成多步骤任务（如发消息、订外卖、整理文档）。简而言之，具备感知能力和自主规划能力的桌面版RPA。很多观点认为，突破口在视觉模型的能力提升，我也是这样认为的，所谓的智能体之眼。
此处，再次强调：极简化设计，less is more。不要试图在操作端，做功能堆砌，这个想法真的会很糟糕。不要为了体现自己强大而密密麻麻的摆放功能，更不要说是用户都用不明白、还要投入学习成本的功能。我们追求的是用户操作的极致体验，是效果，是爽感。
生成式UI：基于LUI规范，以自然语言交互为基础，由模型来选择生成UI表单的实现。好处是，表现形式比起文本方式更丰富也更直观，毕竟人对图的识别和观感本就是优于文字的。而且，在这里可以加入很多个人的偏好，用更适合我的阅读习惯来生成UI。以前的B端UI设计，有一个很容易被诟病的点就是不好适应用户习惯的千人千面，毕竟我不能为每个用户专属定义一套UI，成本太高，而现在，这个问题解决起来就没那么麻烦了。
AG-UI组件：基于AG-UI规范，构建前后端交互的过程、定义前后端交互的标准报文格式、定义前端的标准化事件。自此，便可实现由前到后完整的事件流设计，LUI驱动的UI设计也会更流畅。
-
它不是什么：它不是一个新的 UI 库，也不仅仅是通信与报文的封装。
-
它是什么：它是一套标准化的 JSON 数据化的事件流（JSON Event Stream） 规范。包含前端SDK和后端SDK（暂时先提供Java的SDK）两部分。
AG-UI 是一个开源、轻量级、事件驱动的协议，用于规范 AI 智能体与用户端应用的连接方式。它以简洁和灵活为设计目标，统一了智能体状态、UI 意图和用户交互在智能体运行环境与用户端前端应用之间的流转方式，从而帮助应用开发者快速交付可靠的、可调试的、开发者友好的智能体功能，同时能够专注于应用本身的需求，避免复杂且临时拼凑的集成方式。
AI管理中心
面向智能体运营者的管理维护端，是维护智能体的工厂，是观测智能体运行情况、分析调优智能体的车间。
在这里，才是大量堆砌功能的地方。因为作为这里的用户，他的工作就是维护智能体，以便于更好的为智能体的用户提供服务。换句话说，他们是智能体的共建者，提供更多的手段让他们能建设智能体才是这里的核心任务。如何服从系统的约束，使用系统，他们是专业的。
智能体开发：按照开发方式的不同，可以分为低代码化的智能体设计和高代码化的智能体托管两种。
智能体设计，提供图形化拖拽的流程画布能力和完整的参数化设定能力。具体风格，参照下coze/hiagent、dify这类工具的设计，即可。重点是积累可重用的智能体模版和可拖拽设定的工具插件，足够灵活的乐高化设计。其用户，更多的是偏业务的人员，不需要特别了解技术原理，只需要了解业务和掌握使用能力的能力。
智能体托管，提供对异构智能体的信息注册能力，且主要针对的是高码方式构建的智能体，注册信息包括url地址、APIKey、启停命令脚本等。其用户，更偏开发人员，自信的认为这是开发人员的工作的一群人。灵魂拷问：用编程语言开发智能体，和用工具参数配置实现智能体，究竟有什么区别？代码效率，仅取决于那部分代码的编写者的代码能力。
发布管理：提供将智能体发布到平台运行环境的操作，并且提供发布日志的追溯、版本更新日志差异比较以及指定历史版本回退的功能。也许，你会想再增加一些对新发布的智能体的一些技术指标进行统计视图展示的功能也未尝不可，比如token消耗量、请求量、用户访问量。就如之前提到的智能体推荐功能设计一样，只是为了充满下页面内容，因为它更适合的去处，是智能体运营。
预览调试：提供对智能体的模拟访问调试功能，注意重点是能和正式调用访问进行区分但逻辑链路与正式调用保持一致。所以，该功能天然的就是对沙箱和Mock有使用需求。
测评管理：对智能体的效果进行测试和评价的功能，提供对测评数据集、评价指标项、测试任务的管理功能，也提供对测评报告的预览和导出功能。
测评管理构建的是完整的智能体运行仿真环境和链路，其作用分别发生在智能体发布前和发布后。智能体发布前，进行智能体的模拟仿真测试是为了在尽可能模拟真实环境的前提下，对运行效果进行指标化打分，去比较预设的目标效果，找到测试效果不满足的项，回馈给技术团队进行专项能力优化。智能体发布后，则是根据真实发生的运行数据进行同样的指标化打分，来进一步确认运行质量，试图找到进一步的优化项。所以沙箱和Mock，在这里同样提供了很重要的技术支撑。沙箱隔离运行环境，保障多任务处理过程中，测试数据的真实性；Mock则是降低了配套环境的构建成本，极大地降低了测试成本。
为什么测评报告是一个重要的功能，因为真正的用户不是技术团队。当然，现今大量构建的测评模块，是在给技术团队使用的，更多的是构建了更底层的测评工具，指标项也是以技术指标为主。但我的观点，依旧是，技术指标并没有那么重要，重要的是业务指标。需要的是以报告为媒介，构建业务团队与技术团队沟通和目标趋同的桥梁，真正要被解释的是业务上的指标效果达成情况，始终的围绕业务设计来构建。
沙箱管理：这里指的是对沙箱和Mock服务的统合管理功能。如果是自用，那么选一个适合自身的沙箱工具和Mock工具来使用即可；如果是作为平台功能的一部分要售卖给客户的考量，那么最好是能支持市面上的多款主流的沙箱和Mock工具，支持切换使用。更重要的，是和预览调试、测评管理这样的功能完成了功能联动，独立的沙箱管理，没有存在的价值。
智能体运营：你可以直观的先简单理解为，这是针对智能体运行的逐层指标项和分析视图的可视化展现，毕竟那是功能展示层面的直观感受。事实上，它能做的更多，当然前提是有足够的数据和有意义的指标项。它能帮我们直观的了解到智能体的运行效果，当然我依旧关注的是业务上的效果。
尤其是大家在大量试水在业务体系里加入智能体的当下，只能跑通功能而不能达成业务效果的智能体，只是一个供赏玩的新玩具。而新上线的智能体，通常都是需要一个跟踪->调优的过程才能逐步达成落地预期的。所以，就需要有一群产品运营的人能专项跟踪的去观测和发现这个过程里的效果数据变化，和调优智能体。就和电商平台总是需要有专门的产品运营人员去不断提升平台上的各项关键数据指标一样。甚至运营的方法，都可如出一辙地先抄过来。那么，相匹配的，就需要配合他们行动的工具功能支撑。产品设计的UI效果上，则是要求好看好看再好看，丑的UI视图就真的还是别做了。要的是版面设计的整体感和层次感，而不是简单的缝合拼凑，没有审美的人真的不必硬做UI。
记忆管理： 是针对记忆体服务而提供的各项参数化设定的配套管理功能。在记忆体服务的约束框架下，提供各项可个性化的参数设定，用于调节企业内的使用偏好，重点就是记忆策略和评分模型的调整。
会话管理： 针对会话数据的查询功能，提供包括对会话内容的查看和智能体执行链路的查看功能。
语料管理： 针对平台的语料数据提供统一纳管的功能，语料数据可用于测评管理、模型优化管理、知识治理等功能。
知识库管理： 针对知识库的统一纳管功能，可对智能体会用到的各知识库提供的相关参数进行设定。也是各知识库内的知识工程类操作的统一入口。
团队协同： 以团队协同作业模式为前提而设计提供的一整套平台内管理功能的统一机制，团队内的成员可进行数据共享和协同作业。
平台内的数据权限隔离，本就是一套平台级的标准化数据权限设计。要点在于将对象设计的标准化和权限设计原则的统一化，然后就是充分的内聚化设计。这样的设计，还是得早点做，因为你会发现，在这个时代编新概念太快，每出现一个新的概念和技术就会对应出现一个新的对象，于是你就需要在管理侧有相应的数据权限设计。先约定一套整体的原则和约束吧，避免每次翻炒。
资源空间： 对构建智能体的资源项进行纳管的统一入口，在这里可以快速的找到构建智能体的各项资源，比如工作流、提示词、Skills等。而且，当我们觉得资源项不能完全满足我们的使用需求时，也可以在原资源基础上快速修改形成新的资源。当然，也可以看到资源项的被利用情况以及评价好坏和排名等。
平台管理
这部分，就是被我称为是个系统就该有的功能部分。属实无聊了些，就列一下他们的名字吧。找个好用一点的开源框架直接集成就可，没必要在这里花精力。
工单管理的作用，仅是为了应付部分管理比较严谨的企业对系统参数修改需要经过有权人的人工审核审批的需求。嗯，是的，内部审计时，有时候也需要这些操作的留痕。
AI门户
作为AI应用中心的统一用户入口，统管了操作中心和管理中心。设计上，轻、稳定和异构系统支持，我会比较看重。毕竟会涉及到许多子应用的集成，这个时候如何让各自系统的适配改动小，而又让用户感觉自己是在一个系统内操作，就显得重要了。
其实几套微前端的框架，能力也基本都够用。只是我个人偏爱wujie的设计罢了。另外，整合多系统的用户体系，也同样重要，毕竟要对用户做到无感切换。
MaaS层
其实该怎么说呢，本质上这一层就是取了PaaS层里关于算法能力的部分，再结合IaaS层里关于算法相关的基建设施管控调度的部分，融合形成的。其核心模块就是作为统一入口的AI网关、对应各样工具能力的算法服务、算力资源的调度工具以及模型优化工具。这些在前面都分别提到过，就不再重述了。
这一层的设计意图，就是让算法工程师的工作能进一步聚焦。把精力都用在优化算法的数据效果，注意我说的是数据效果，而不是任何应用类的性能指标。我并不打算和这个团体讨论什么线程切换、资源占用等等诸如此类的问题，也没兴趣翻看这里的代码结构。只要能跑出有意义的数据效果，那显然更为重要。
DaaS层
这一层的出现，其实也和MaaS层的出现情况大致类似。好处是，让我们更清晰化的去思考和探索数据资产的价值了。
重点还是在识别哪些数据是企业内部的有意义数据，是对业务能产生价值的特征数据。然后才有去沉淀的价值，积累起来的数据才能称之为数据资产。我们建设的系统，已经够多了，在功能堆砌上花费的时间和精力也够多了，可以不用在为了堆砌而堆砌了，想想本来的意图。
于智能体平台来说，知识特别是隐性知识、量化指标项特别是业务指标、技能Skills、工作流、提示词，甚至是可用于微调的训练数据集，这些才是有价值的数据资产。系统设计思路会变，但经过系统产生的数据却是永存。
写在最后
为什么说已是最后，大体是因为觉得聊的差不多了。非要说，还有什么，大约就是两地三中心的多活方案、硬件配置、AI组织建设之类的，属实兴趣不大，这类套了公式按照业务流量和数据体量拍着脑袋的计算，基本都是超配。也有技术爱好者构建了很酷的NaaS层设计，但我实在是提不起兴致。
浅浅提一句AI组织建设，组织成员是真的理解和接受了AI协同了么？在这样的组织里，AI与人，平权了么？建设目标真正统一了么？是可以促进业务发展的建设么，体现在哪儿了？还是那一句，不要为了建设而建设，然后只是花了一堆的token，迎来了AI与人的相互掣肘。
系统终归是系统，系统设计也终归是系统设计，并不会因为处于AI时代就跳出了约束。如果有，那就是你并没有真正理解什么是系统，对原本的边界和约束存在误解。不过是大家为了各自的目的和设计意图，把前人走过的路又去走一遍罢了。当然，还顺便制造了一堆相似的问题，然后又一次的自诩解决问题，可就不知业务问题是否真的解决了。就这样吧，累了，不想聊了。
就以此文献给那些还在智能体平台建设路上持续奋斗的伙伴们，或共鸣、或参考、或带偏，反正也都不是我该想的事儿了。当然，依旧希望大家都能快乐而有目标的前行，能看清前路，能知晓归途，不忘初心。
不知为何，此时很想接一句我喜欢姑娘的口头禅：懒得喷！
