从云原生体系建设，到大模型爆发下的智能体浪潮，AI 正在重构企业软件的构建方式。很多企业热衷于追逐模型、Agent 框架等新概念，但在真实的产业落地中，框架选型、酷炫 Demo 只是起点，如何处理模型不确定性、做好 AI 工程化、平衡理想架构与企业现实约束，才是决定项目成败的核心。
近日ITPUB 专访亦民亦信息技术（大连）有限责任公司 CTO 匙亮旭老师，本次访谈围绕云原生到AI 原生的技术演进、智能体企业级落地实践、AI 团队建设、大模型项目风险规避、技术理想与商业现实平衡等话题，分享兼具一线实战与产业咨询视角的深度思考。
01
十余年技术之路：从技术专家到产业赋能者
问题1：您同时有企业 CTO、高校外聘讲师、技术社区主理人、企业 AI 咨询顾问多重身份。不同身份视角下，看待同一个 AI 落地问题，经常会有不一样的判断。多重身份会给您带来哪些认知优势，又会带来怎样的认知冲突？平时如何完成视角切换？
在您问这个问题之前，确实没有仔细思考过，因为从不同的视角，不同的方向，不同场景下去看待AI的问题，得到的结果确实往往不同，但最终都会融合到一起。例如，从作为一个软件公司CTO的角度去看待AI落地，更加关注的是公司内部如何建设好软件工程的AI工程化体系，并且要时刻关注市场和AI技术的发展，辅助领导做公司的战略决策，让公司走在正确的道路上；作为高校的外聘讲师，则可以从学生和老师的身上了解到AI在高校内的使用现状和学生的核心诉求，也会从一些科研项目中看到AI在高校内具体是如何应用的，大家的发力点在哪，和企业AI落地有什么区别；作为《极客e家》社区的主理人（我这个是纯技术社区），从日常公众号大家的阅读量和评论，从知识星球中各类AI资料的下载量和从日常技术交流群中可以发现，大家最关心的AI技术方向是哪些，AI在一些细分技术领域掌握的如何，大家的技术痛点一般都集中在哪些AI方向上；而给各类企业做AI数智化转型咨询，更是可以从各行业中发现大家的核心诉求（最近几年我集中在能源、工业、制造业和新能源的某些细分领域），在AI转型中大家的痛点和企业高层对整体转型的一个思路，这些经验对我来说真是太宝贵了，尤其走的企业多了，场景和痛点见的多了，转型中失败的案例也见的多了，可以使我在做企业AI转型咨询时更好的提出靠谱的方案，去支撑我更好的落地去解决具体问题；除此之外，我偶尔也会去一些软件公司做AI方向的企业内训，也会看到其他一些软件公司AI转型中好的方法......上面这些宝贵的经历，最终都会让我不停的成长，提高AI认知的同时，积累不同角色和各个方向的经验。如果说认知冲突层面，这个我还真没感觉到，也没有说刻意的在不同角色和思维间进行切换，因为AI的各种阅历已经融入成为了我AI认知和知识底蕴的一部分，面对任何场景，都会自然而然的将背后的经历和方案经验等相结合，去更好的应对未知的需求。
问题2：行业普遍存在一种心态：寄希望下一代更强基础大模型，靠模型能力绕开企业内部业务治理差、知识沉淀混乱这些老问题。结合您大量落地经验，技术真的能够绕过企业业务和组织层面的固有短板吗？这种心态会给企业AI 建设带来什么误导？
我认为100%绕不开，我都可以100%确定给出这个回答。各行业某些细分的业务领域，在给企业做AI转型咨询的过程中，虽然转型过程中各类问题很多，而且多数前期都是以失败而告终，尤其想一次性就成功是很困难的，但最核心的重点问题我总结后也就3大类。首先是部分流程和资产难以数字化，或者说数字化下来成本太高，这个是解决不了的，尤其在工业和制作业等领域的某些流程中，你如果没有办法将资产数字化，大模型就很难发挥作用；其次是已沉淀下来的数字化资产难以形成高质量的数据进行微调与强化学习和使用知识库方式进行知识沉淀，也可以说最后结合企业私有知识使用的过程中，幻觉率太高，达不到生产级使用标准，多数都是Demo级别的智能体（这里还蕴含着企业知识私有化时，模型和算力的一个平衡）；最后就是企业的组织、流程和人为因素了，这个就不详细说了。所以哪怕以后模型做的再小再强，都绕不开如何结合企业实际情况去应用，这是两个维度的事情。现在还有一个问题这里也提一下，我认为这个误导反而更大，因为现在AI的社会普及度已经很高了，尤其去年过年时的DeepSeek更是给全民普及了一次AI，很多老板和高层也会看一些自媒体或商学院等发的企业AI转型成功的案例，就想着往自己企业去套用这些方法，找公司几个人负责就开始铺开干，但往往以失败告终，后续各种追责......这背后其实有着很深的哲学在里面，这里不展开具体说了，但我说的这个事，我认为这种心理带来的误导更大，做咨询时很多老板和高层本身就很焦虑，因为股东们和投资人都在看着你怎么做AI，都有着类似的错误认知，以为可以复辟别人的成功，不是说你照着去做100%不会成功，只是成功的概率是很低的，不建议盲目冲动去尝试。
02
智能体与AI 原生架构落地实战
问题3：当前智能体开发框架层出不穷，很多团队上手就开始写Agent 业务逻辑，但随着工具调用、记忆模块、多轮规划、多智能体协作不断叠加，系统复杂度快速膨胀，出现 “框架越强大，系统越难维护” 的困境。在企业人力、预算有限的前提下，从架构治理层面，可以通过哪些手段约束智能体系统的复杂度持续上涨？
这里，我先从非技术角度去看待这个事。我认为前期，大多数智能体场景下，是没必要花时间把Harness做的那么完美，这是有问题。前期我们需要的是MVP阶段，快速使用Vibe Coding方式用最小的成本先做出一版能跑通核心流程的产品让用户去使用，如果大家对产品认可，使用频率高，那再去深度打磨Harness是有价值的，否则就应该及时止损。然后，我们再来从技术角度去聊聊，想做好一个Harness是特别困难的，包括今年5月份我在中国系统架构师大会上也做过分享，在业界首次提出了一个好的Harness架构应该是7+2的架构组成，既有功能性需求，也也考虑非功能性需求，Harness根据不同的需求，可大也可小，可以做成项目级也可以做成平台级。要打磨好一个好的Harness，从框架角度去看的话，我认为各家框架都差不多，该有的核心特性都封装的不错，直接调用即可，开发的复杂度上也都不会相差太多，并且现在都是AI编码，实现起来都很快，反而关键在于前期结合业务，把事想清楚，把底层架构设计好更重要。如果想省事，直接用一些开源的Harness项目作为骨架去开发也没问题，例如使用最近非常火的DeepSeek Harness或者PI等，如果某个功能特性不符合需求，二次开发迭代即可。所以，最后这里我要说的是，AI技术发展太快了，Harness也是不停的在变化，例如去年知识库的主流还是RAG，现在都变成了LLM Wiki + RAG + Ontology，采取双路检索的方式。所以，你这个阶段Harness哪怕打磨的再好，可能一周后就会落后了，我的建议是，最小限度符合核心功能性与非功能性诉求情况下，够用就行，别过度追求完美。
（企业级智能体7+2架构）
问题4：当前开源智能体框架百花齐放，LangChain、LlamaIndex、AutoGen 等各有侧重。面对纷繁的框架选型，企业应该建立一套什么样的评估标尺，避免追新跟风？什么场景适合重度依赖开源 Agent 框架，什么场景反而建议轻量化自研，减少框架绑定？
业务驱动技术发展，技术发展是反哺业务的，所以结合当前业务场景，如何选择合适的技术是特别重要的。并且这个问题本质上，和是不是做智能体，我们是不是处于AI时代没太大关系，本质就是一个架构层面的技术选型问题。说下我个人的一些观点，仅供大家参考：
1、先想清楚业务是什么，要解决哪些问题，功能和非功能性需求的关注点在哪，结合开发成本和工期，然后再考虑有哪些备选的框架符合，都符合哪些特性和功能，匹配度是多少，技术复杂度如何，每个框架不符合的那些Harness能力，如果自研的话成本大概是多少。。。。。。所以类似于各类维度，需要做个表格进行比对，尤其现在有AI的情况下，做这个事更加方便了。
2、某个技术或框架的社区的活跃度和团队技术的熟练匹配度，这个往往是很容易被忽视的，即使现在有AI的情况下对于开发语言的要求越来越低。
3、如果可以在调查的过程中，非常快速的进行技术验证，可以极大限度降低选型成本和风险。
然后说一下我个人的经验，如果说你的项目需要大量的通用能力，这些能力往往现在的框架都肯定是具备的，所以这时候可以选择使用基于开源框架去开发；如果说你的业务核心机制需要高度定制化，通用性很低，那这部分就要考虑轻量化自研了；又或者说你就是对性能有极致要求，即使有很多通用能力符合开源框架需求，但就是感觉使用开源框架太重了，那肯定就要自研去写了。现在其实很多场景，尤其多智能体协作，每个SubAgent都可以选择不同的技术框架+自研这种组合的方式去实现。
最后，这里又想到了一个其他的事，大家感觉，现在这个AI时代下，是技术广度更重要，还是技术深度更重要。我个人的观点是：AI时代下，往往技术广度比深度更重要。因为技术广度，在我们面对业务问题时，肯定是需要知道有哪些技术可选，每个技术都有什么特性，可以解决哪些问题，又有哪些限制。如果技术广度不够，就容易不管遇到什么问题，都套用自己最熟悉的那套方案。而技术深度，无论是以后具体技术的学习、落地或者是后续问题的排查，现在有了AI辅助，都可以帮你实现去解决具体问题，这个是AI特别擅长的。所以说到这里，更是可以体现出前期技术选型对于技术广度经验的依赖。
问题5：RAG 是企业落地大模型最主流的方案，但大量项目上线后遇到知识库更新滞后、文档质量参差不齐、召回不准的问题，很多团队把问题全部归咎于向量库。真实项目中，向量数据库在整个 RAG 链路里到底应该承担什么样的定位？哪些问题是向量库解决不了的？
你说把RAG效果不佳的锅甩给向量库，那有点欺负人家向量数据库了，向量库要是有生命，它心里的独白会是：我就是一个用于存储和查询的中间件，是你给我的数据我没存储好，丢数据了？还是查询时，我没按照要求把数据查丢了查错了？RAG不好用的核心锅不在我头上，你自己不检讨下入库前和出库后的策略吗？
上面，我用向量库独白的方式，解释了向量库的定位，就是一个存储的中间件而已。您问题提到的，知识库更新滞后、文档质量参差不齐、召回不准等问题，都是RAG整体策略的问题。下面，我用之前画的一张知识库解决方案图，简单聊一下这个事。
（基于LLM Wiki + RAG的知识库方案）
这里我们先不考虑Ontology（本体），现在主流知识库的实现方式是LLM Wiki与传统RAG相结合的方式，整体流程上没有变，还是向量数据库作为分界点，分为知识的构建和知识的召回两部分。其中LLM Wiki和核心就是来解决知识库更新滞后的问题（因为构建成本较高，建议半夜定时去跑Wiki知识更新），只不过知识构建的过程中，相比于之前RAG的流程只对原文进行索引构建，现在还多了Wiki索引构建的流程。在知识索引构建入库的过程中，你的数据质量，数据处理环节，分块策略，Embeding过程等都将极大影响着后续知识检索的质量。然后再来聊聊Retrieval，也就是知识召回，相比于之前RAG的知识检索流程，这里我就直接推荐使用双路召回了（原文检索索引和Wiki检索索引的召回都要做），向量数据库检索过程中，使用向量检索的策略是什么，是关键字匹配，还是语意匹配，还是两者的混合模式，取Top k是多少；检索后，你对检索的结果进行合并、去重、重排等处理了吗；检索前进行语义澄清了吗......所以上面举例说的这些因素，都会极大影响知识库使用的最终效果，也都是向量库解决不了的问题。
问题6：AI 生成内容标识、算法备案、数据不出域、权限隔离、输出风控、可审计追溯，一系列合规要求正在深刻影响 AI 系统架构。在众多合规约束里面，落地智能体项目时，哪一项最容易被技术团队低估，进而埋下后期整改隐患？
这个问题正好又对应了我提出的【企业级智能体7+2架构】中的这个2，代表着左右两侧的横切关注点：左侧是可观测性与评估，也就是我们日常说的链路追踪和测试，但这个测试不是侧重于功能好不好用，而是输出内容的质量如何；右侧是安全治理与合规，其中包含了数据出入模型的安全性和合规性等问题，还有模型输出内容针对用户的数据权限问题。这两个看似都不影响核心业务，但往往都最容易被技术团队低估。其实针对这部分，我没过多说的，要是做的智能体是产品级或企业级标准，想都不用想，这两者都需要有，而且很重要；但如果只是内部可用的智能体，标准可以不用那么高，因为做这两个事，很花精力，往往比你实现核心业务功能的时间还要长，成本还高。然后最后说说，生产级智能体你要是不做这两件事的话，到底后期可能会埋下哪些重要的隐患：首先，如果可观测性不做，就无法去追溯和排查问题，也无法进行调优，这个是最重要的；其次，如果评估不做，就不知道智能体输出的内容和执行结果的好坏，更无法从中调优知识库和提示词等；如果安全治理与合规不做，就很容易出现数据或敏感信息泄漏，权限失控等问题，后期补救的话，成本都特别高。
03
AI 与智能体项目的技术债务深层思辨
问题7：很多企业会采购AI 大模型平台、低代码 AI 应用平台，希望降低开发门槛。但落地之后反而形成新的技术黑盒，业务被平台锁死，定制改造困难，在引入这类商用 AI 平台的时候，技术负责人要提前设置哪些 “防锁定” 条件？
在2026年的现在，真还会有企业首选用低代码平台去开发智能体吗，即使有，我认为应该非常少了吧。你要说截止到2025年上半年，用Dify或Coze这类低代码平台去开发智能体确实是很多企业的主流选择，但现在都倾向于用Vibe Coding方式手搓一个吧，毕竟低代码平台方式创建智能体也就是一些简单的场景，完全可以用Vibe Coding方式取代了，尤其Goal的这种思想更符合不看过程只看结果的场景。但并不是说他们完全退出历史舞台了，例如RAGFlow这种低代码知识库平台还是很有竞争力的，包括现在还有很多时候Dify+编码相结合的方式去创建智能体，也会省很多成本，而n8n这种侧重于工作流的平台，因其扩展生态的强大性，一定不会被舍弃的。所以你要说从降低开发门槛的角度出发去使用低代码平台创建智能体，相比于Vibe Coding，已经没有竞争力了，不能作为一个选择的理由了；你要说技术黑盒，我感觉也说不通，因为简单的场景才会考虑用低代码方式去构建，调试也相对简单，低代码平台即使黑盒也不会有啥大问题；复杂场景下，从一开始的技术选型上，就不应该使用低代码方式去构建，所以我认为低代码技术黑盒这个事确实是事实，但是场景很少，影响也不大。而且我从AI技术的发展角度去看，低代码平台构建智能体的方式，会越来越边缘化，除了极个别难以替代的，大多数终究会死的很快的，当然，这话有些说的过于绝对了，肯定也是分场景的。
问题8：现在模型迭代速度极快，每隔几个月就有新一代基础模型发布。企业已经上线的AI 业务，要不要紧跟潮流频繁升级底层基础模型？频繁升级模型会带来哪些隐性成本与风险，升级底层模型的决策依据是什么？
这是个特别好的问题，也是大家很容易忽视的一个问题。这个问题需要从你的模型是私有化部署的，还是使用公有的大模型平台，因为思考的方式是不同的。首先说接入的公有的大模型平台，如果你之前接的模型，因为上了新模型，平台要强制废弃旧模型，那你没有办法，就是需要被动的升级你的模型和对应的Prompt，包括相关的Harness；如果说你的业务在稳定运行，效果客户还满意，那无论是私有部署的大模型还是接入公有平台的大模型，都不需要为了升级而升级，这里我们就可以参考日本的很多老旧系统了，能稳定的跑，也没有什么新业务需求，没必要升级。
然后，再来说说，如果升级的话，成本有多高，因为随着模型能力的越来越强，新模型的很多能力，就会吃掉原来你Harness实现的一些功能，所以你升级模型后，尤其是跨的模型版本非常大时，甚至你直接就换了一个其他厂商的大模型，你的Prompt和Harness一定是需要大改的，甚至重构，随之而来所伴随的就是大量的测试和输出质量评估，所以要升级模型的成本是很高的。
最后，我个人的建议，或者说策略吧。模型升级，第一步换完模型后，其他的不变，评估效果，依据效果再采取后续的策略；或者更激进一些，与其模型升级和花时间做各类评估和想策略，不如就重构得了，用最新的模型和Harness框架进行重构；或者原有工程支出一个新分支，在此基础上大改。现在遇到的很多场景，真就是因为升级模型后，因为升级Harness的成本太高，直接就重构了。
04
AI 浪潮之下：理性看待技术红利
问题9：您同时服务创业公司和传统大型产业客户，不同企业的AI 成熟度差异巨大。面对完全零基础的企业，AI 转型第一步不应该做什么？很多企业的第一个 AI 项目就选错了场景，直接导致整个 AI 转型信心受挫，该如何挑选企业第一个 AI 试点场景？
我认为这也是一个非常好的问题，因为创业公司和传统大型产业客户，老板对于AI应用的思路是完全不同的。创业型公司，核心诉求是花小钱办大事，想用AI解决核心问题，最大限度追求转型带来的ROI，上来AI直接就作用于核心流程；但是传统大型产业客户可不敢那么玩，前期都会谨慎的收集诉求，找专家做咨询，先作用于非核心业务试水，然后再逐渐深入核心业务，所以思路是完全不同的。
AI转型失败的因素有很多，创业公司成功的概率和速度也要高于传统大型产业客户，这个与AI出现前，企业做数字化转型的原因都是一样的，毕竟航母掉头哪会这么快。很多企业转型失败，往往是做决策的人认知有限，可能是去外头参加各种AI大会，和多个专家进行了交流，看了很多转型成功的各类白皮书，心理也有了预算和想做的事，一开始就想把事做好，把事做成，但往往最后事与愿违，钱也花了，东西也确实做出来，但是没人用，根本原因是不好用，最后一地鸡毛。
所以，结合我之前做AI咨询转型的经验，我的建议是，无论你是创业公司和传统大型产业客户，转型的试点场景和群体，一定要选择数字化资产程度高，信息化办公程度高的中小部门，往往这部分人的AI认知会高一些，配合度也会高一些；然后从这部分群体出发，找ROI较高、风险相对较低的1～2个核心场景开始推进，这里注意，一定要是核心场景，不要边缘场景，否则即使成功了没有说服力；所以先致力于把这1～2个场景做好，拿到数据，作为典型成功案例向高层汇报和员工内部渗透，得到支持后进而再持续推进，成功的概率高一些，尤其员工的配合度会高很多。
最后给出一个建议，如果企业内部没有AI专家，前期还是做AI咨询可以少走很多弯路，否则找企业内部一些半吊子负责做这个事，试错成本太高，最好还是回归找专家这条路。我接触的很多企业，都是前期不舍得花钱，自己闷头搞AI，最后失败后还是得找咨询善后。
问题10：沉没成本下，企业已经投入的AI 平台明显不匹配业务，但管理层拒绝替换。技术负责人说服失败的前提下，除了妥协，还有哪些风险控制手段？
这个问题是一个很现实的问题，也是所有做AI转型的企业都会遇到的问题。AI还在不断的发展中，你2024年AI做出来的东西，2025年看已经落后过时了；你2025年训练出的模型和做的智能体，现在看来也是过时的；同样的，你现在做的东西，明年看，甚至几个月之后回头看，还会是过时的。因为AI一直没有走到终局，企业的业务同样也在持续发展，你在此过程中作出的东西，蕴含了大量的沉没成本。
而管理层投了钱、时间和大量人力做出来的东西，即使不好用，过时了，与现阶段业务匹配度高低，也都是曾经为AI买过单的，如果放弃不用，也就间接承认了当初一些决策上的失误，钱打水漂了不说，还面临着绩效和问责等压力，所以总需要有人会为这些沉没成本买单才行。尤其经历过这些沉没成本的投入之后，他们也不愿意再砸钱去投入了，因为没人能确定这是不是又一次的沉没成本。
所以，如果从技术负责人的角度想要主动去推成功这个事，说服高层持续投入，确实是很困难的，尤其高层认知有限的情况下。那这时，以下是我个人认为比较好的控制风险的手段，也仅供参考：首先肯定是及时止损，新的业务就不要继续往AI平台上加了，现有的AI平台只跑已验证过可用的业务即可，并且还要随时关注这些业务流程的匹配度，关键环节一定保留人工审核，避免因AI平台匹配度问题而直接变成业务事故；其次，跟高层说明继续使用可能造成的业务影响，记录风险接受人、处置责任人和应急方案等，降低风险；最后，核心数据和业务规则要提前积累，为未来做准备，因为现在不替换，不代表未来不替换，除非企业未来明确不会为AI再投入，想办法跟领导约定改善的期限、投入上限和验收指标等，例如任务成功率、人工返工量、单次任务成本，如果达不到约定标准，就暂停或重新评审，而不是不断追加资源。
嘉宾简介：亦民亦信息技术（大连）有限责任公司CTO，大连理工大学外聘AI讲师，「极客e家」技术社区主理人，腾讯云架构师北京同盟成员。长期专注于人工智能、智能体与云原生技术研究及企业级实践，曾为多家传统企业提供AI转型咨询、技术规划与应用落地服务，并负责过大型科技企业的技术团队建设与技术委员会工作。著有《LangChain 1.0智能体开发实战》，曾推出《从0开启AI实践之旅》课程，持有 AWS、Azure、GCP专家级解决方案架构师及CKA等云计算领域专业认证。目前主要聚焦AI原生架构、模型训练与优化、智能体及企业AI工程化落地。公众号与知识星球账号：极客e家
热门跟贴