Ricky

互联网巨头纷纷下场推出AI产品,发布各种各样的Agent,企业应该如何打造属于自己的AI能力?

互联网巨头纷纷下场推出AI产品,发布各种各样的Agent,企业应该如何打造属于自己的AI能力?

2026年以后,AI产品的竞争已经从模型参数和榜单分数,逐渐延伸到工作入口和任务执行。大厂开始密集推出AI助手、Agent平台、编码工具、企业知识产品和AI工作台,很多产品的完成度都不低,既能对话,也能接插件,还能在演示里完成一串相对复杂的任务。对企业来说,这类产品当然值得关注,因为它们降低了员工接触AI的门槛,也让业务部门更容易理解AI可以进入哪些工作环节。 但企业如果把这件事理解成“买一套大厂AI产品就完成了AI建设”,后面大概率会遇到落地问题。通用AI产品解决的是共性入口和基础能力,它们不可能天然理解一家企业自己的产品口径、客户规则、审批习惯、数据权限和历史系统。员工用起来觉得方便,和企业把AI沉淀成自己的组织能力,中间还隔着业务流程、数据治理、系统集成和持续运营。 很多企业前期AI试用很热闹,后期却很难进入核心流程,原因就在这里。不同部门各自采购工具,各自搭知识库,各自写提示词,看起来每个团队都有AI助手,但组织层面没有沉淀出可复用的Agent能力,也没有形成统一的权限、日志和成本管理。工具变多以后,AI反而可能变成新的信息孤岛。 通用AI产品可以作为入口,企业AI能力

By Ricky
54起AI失控的背后,企业如何引入安全可控的Agent能力,让AI不再是危险盲盒

54起AI失控的背后,企业如何引入安全可控的Agent能力,让AI不再是危险盲盒

进入2026年以后,Agent的行业叙事有点降温,但不是因为大家不看好它,而是很多企业开始从演示效果回到生产环境。前两年讨论Agent,焦点常常放在它能不能自己拆任务、调工具、交付结果;现在企业更在意的是,Agent如果真的进入业务流程,它的动作谁来约束,异常谁来处理,出了问题能不能复盘。 Gartner相关调研显示,不少组织计划在未来两年内部署Agent,但真实落地比例仍然偏低;IBM面向C级技术高管的调研也提到,受访企业过去一年平均遭遇了54起Agent相关失控事件,其中一部分属于高危。具体数字在正式发文前还建议回到原始报告核验,但这个现象已经足够有代表性:企业对Agent有期待,也有很明显的不放心。 这些数据最值得关注的地方,不是把Agent简单写成“危险技术”,而是把问题放回企业系统里看。Agent的问题不只是回答错,也不只是模型幻觉。它一旦开始调用工具、接触数据、推动流程,风险就会从内容质量扩展到业务执行。 Agent为什么总被卡在小范围试点 很多企业最早接触Agent时,通常会被它的执行感吸引。它不像传统对话助手那样只给一段回答,而是能理解目标,拆出步骤,借助工具

By Ricky
从DEMO到落地,央国企引入AI能力走入合规深水区,如何在合规的前提下提高效率成为关键

从DEMO到落地,央国企引入AI能力走入合规深水区,如何在合规的前提下提高效率成为关键

央国企AI建设正在从办公助手和知识问答,进入更接近生产系统的深水区。文章围绕集团统建底座、业务场景选择、信创环境适配、数据治理和运行审计展开,重点讨论央国企规模化引入AI时,但也不能只看模型效果,还要提前考虑国产化环境、权限边界、任务闭环和持续运营能力~ 过去一年,央国企对AI的关注点在变化。早期更多是在验证模型效果,看看知识问答准不准,材料生成能不能减轻一点办公负担。进入2026年后,很多单位开始把Agent放到生产管理、安全审查、采购供应链、经营分析和研发设计这些更接近主业的位置,项目的复杂度也随之提高。 这种变化其实很现实。一个办公助手做得好,通常只影响一类人员的工作体验;一个生产管理类Agent要进入系统,就会牵涉权限、流程、接口、审计和运行环境。前者可以快速试,后者要经得起集团范围内的复用和安全审查。央国企真正要处理的,是AI能力如何在集团范围内被统一建设、分级使用、持续运营,并能通过信创、安全和审计要求。 集团做底座,业务单位做场景 央国企的业务线长,组织层级多,系统边界也复杂。AI能力如果都由各单位单独建设,短期内看起来推进快,后面会出现一批相似问题:模型接入方

By Ricky
个人用AI变快了,企业为什么还没真正提效?

个人用AI变快了,企业为什么还没真正提效?

2026年,企业内部使用AI已经很常见。员工用AI准备材料、整理数据、生成方案,一些岗位也开始尝试让Agent代为处理任务。管理层能听到不少正向反馈:原来半天才能完成的工作,现在一两个小时就能交付。 但把视线从个人工位移到整个组织,情况通常没有这么直接。项目周期没有明显缩短,审批和系统录入仍然依赖人工。这里真正要讨论的,不是AI工具好不好用,而是企业有没有把AI能力放进一套可运行、可治理、可复用的组织系统里。 个人提效,常常只加快了一个节点 很多员工最早感受到的AI价值,来自自己可以独立完成的工作。过去需要从多个文件里找资料,现在可以让AI先做整理;原本从空白页面开始写内容,现在可以先生成一版初稿。企业流程要长得多,一份客户方案生成之后,可能还要经过产品确认、合规审核和业务审批,随后由另一名员工录入系统。前面的材料产出从一天缩短到一小时,后面的处理方式没有变化,节省出来的时间很快会被等待和返工抵消。 观察维度个人AI提效组织级AI提效工作单位单个操作或局部任务一段可完整交付的流程能力来源个人工具和使用经验企业可复用能力系统关系人工复制和切换在授权范围内连接系统运行状态发出

By Ricky
从17.3%到40.3%:企业Agent跑得越快,越需要一层安全底座

从17.3%到40.3%:企业Agent跑得越快,越需要一层安全底座

企业AI Agent的采纳率在上升,真正的考验也开始后移:从“能不能跑通Demo”,转向“能不能在真实业务里受控执行”。当Agent开始调用工具、访问文件、运行脚本,安全边界就不能只靠提示词维持。 企业AI Agent正在从试验项目进入正式采购和平台建设。 采纳率从2024年底的17.3%,上升到2026年中的40.3%,背后不是一个简单的热度变化,而是企业对Agent的角色预期变了。 它不再只是创新团队里的演示能力,也不只是员工工作台上的问答入口。越来越多企业开始希望Agent接入内部流程,处理更具体的任务,连接文件、接口、工具和业务系统。 但在ToB软件场景里,采纳率提升不代表生产级成熟。Agent能在演示环境里跑通,和它能进入真实业务流程,是两件不同的事。 Agent不是聊天窗口,而是执行单元 过去很多AI应用更接近问答入口。员工输入问题,系统返回答案,最终由人判断是否采用。即使结果不够好,也可以用人工复核兜底。 Agent的变化在于,它会产生动作。它可能调用工具,运行代码,读取文件,访问接口,还可能把一个任务拆成多个步骤持续推进。对企业来说,这已经不是一个简单聊

By Ricky
为什么AI采购会让CIO焦虑?

为什么AI采购会让CIO焦虑?

2026年以来,企业AI采购的节奏明显变快。老板层面关注同行有没有开始AI改造,业务部门希望尽快把Agent能力引入到具体工作里,安全和合规团队则不断追问数据边界、权限控制和审计责任。AI不再只是一个由IT部门评估的工具,而变成了一件牵动业务、采购、安全和管理层的组织决策。 这种决策最让CIO焦虑的地方在于:不买怕掉队,买了怕失控。前者来自市场压力,后者来自企业内部的运行责任。一个AI产品在演示中表现得很好,并不代表它进入企业环境后就能被长期管理;一个Agent能完成任务,也不代表它的身份、权限、工具调用和执行过程已经被企业接住。 一、过去买软件,今天买“执行能力” 传统软件采购的逻辑相对清楚。企业评估功能、价格、部署方式、服务能力,再决定是否购买。系统上线后,真正的操作仍然由员工完成,软件本身不会主动决定下一步要做什么。 AI采购的复杂性在于,它不再只是买一个系统界面或一组功能模块。尤其是Agent出现后,企业采购的对象开始带有执行能力。它会理解任务,拆解步骤,调用工具,处理上下文,再把结果交付出来。CIO要评估的,也就不只是“这个产品好不好用”,还包括它在企业环境里怎么运

By Ricky
听起来很美好的“数字员工”,如何安全可控地引入到企业流程中来?

听起来很美好的“数字员工”,如何安全可控地引入到企业流程中来?

今天分享一下“数字员工”这个听起来很美好的概念,真正进入企业流程时要补哪些东西。 AI Agent和数字员工的讨论越来越热。很多文章会把它描述成一位永远在线的新同事,可以查资料、写材料、跑流程、交付结果。这个说法很容易传播,也确实抓住了Agent和传统问答助手之间的差别:它不只是回答问题,而是开始参与任务执行。 但企业真正引入数字员工时,最好不要被“员工”这个拟人化称呼带偏。数字员工不是一个更会聊天的账号,也不是给每个岗位配一个AI头像。它一旦进入企业流程,就会变成一个受托执行角色:代表谁做事,能看什么,能调用什么系统,什么时候必须停下来等人确认,出错之后由谁处理,这些问题都比“它是否聪明”更早进入生产环境。 一、中小团队可以先试,中大型企业不能只靠试错 如果是中小团队,数字员工的引入方式可以更轻一些。团队规模小,流程短,数据边界相对清楚,很多时候可以先把工具用起来。用得好的场景保留下来,用得不好的直接丢弃,试错成本不高,审批链条也没有那么重。 中大型企业的情况不同。组织层级更长,系统更多,数据类型也更敏感。一个数字员工如果接入了客户资料、财务数据、

By Ricky
后龙虾时代,企业级Agent从“能用”到“生产级”差距在哪里?

后龙虾时代,企业级Agent从“能用”到“生产级”差距在哪里?

OpenClaw、Hermes这类工具火起来之后,很多人对Agent的预期被重新拉高了。它不再只是回答问题,也不再只是帮人改一段文案,而是可以拆任务、调用工具、处理文件、执行命令,最后交付一个相对完整的结果。对个人用户来说,这已经足够让人兴奋;对企业来说,这反而把一个更麻烦的问题推到了台前:如果AI真的开始“做事”,它应该被放在什么样的生产系统里运行。 过去评价一个AI应用,常见标准是回答准不准、速度快不快、交互顺不顺。到了Agent阶段,这些标准还不够。一个Agent能跑通一次任务,只能说明它“能用”;要进入企业生产环境,还要看它能不能承受组织级并发、权限继承、异常恢复和审计复盘。这里的差距,不是体验上的差距,而是工程体系上的差距。 一、后龙虾时代,企业开始重新理解“能用” 很多Agent工具最开始打动用户的地方,是它把AI从聊天框里拉了出来。用户不再只是问一句、等一句,而是把一个目标交给Agent,让它自己理解任务、选择工具、生成中间结果,再把最终结果交回来。这个变化很重要,因为它让AI第一次像一个可以参与工作的执行单元,而不是只提供建议的问答系统。 但企业内部对“

By Ricky
为什么大部分AI只能停在Demo阶段:企业如何设计安全技术底座,让Agent真正产生价值

为什么大部分AI只能停在Demo阶段:企业如何设计安全技术底座,让Agent真正产生价值

为什么很多AI项目在演示阶段看起来不错,到了企业内部却很难持续产生价值。 因为AI Coding能力的提升,很多项目从PPT阶段变成了DEMO阶段,因为可以快速借助AI来搭建一个DEMO,但从DEMO到落地,仍然存在非常大的鸿沟,今天分享一下,企业如何真正的将AI能力引入到企业的真实工作流中~ 过去很多AI应用停在“问答助手”阶段,风险相对可控。员工问问题,系统给回答,最多涉及知识库检索和内容生成。Agent出现之后,情况变了。它会拆任务、选工具、读文件、调用接口,甚至执行脚本和写回系统。AI一旦从“生成内容”走向“执行动作”,企业就不能只评估回答质量,还要评估整个执行链路是否可控。 一、AI让DEMO变得越来越廉价 很多AI Demo的架构都很轻:一个聊天页面,一层应用服务,一次大模型调用,再加几个工具函数。用户输入任务后,模型生成计划,应用层执行工具,最终把结果拼回聊天窗口。这个链路足够短,适合验证想法,也适合让业务方快速看到效果。 问题在于,Demo环境默认了很多企业环境里并不存在的条件。它默认只有少数测试用户,默认工具调用不会越权,默认任务可以很快结束,

By Ricky
企业缺的不是AI能力,而是能够嵌入到流程的Agent体系

企业缺的不是AI能力,而是能够嵌入到流程的Agent体系

企业现在并不缺AI能力,真正缺的是把AI能力嵌入流程的方式。只有当Agent可以被发起、被授权、被执行、被记录,并且能够把结果回到业务系统里,企业才会把它看成组织级能力,而不是员工个人效率工具。接下来分享一下,如何搭建不一套能够承接数字员工、业务流程和安全执行的Agent体系。 今天分享一下企业引入AI时很容易被忽略的一个问题:很多公司并不缺AI能力,员工也并不是不会使用AI工具,真正卡住的是这些能力很难稳定进入企业流程。一个员工在聊天窗口里让AI帮忙整理材料、写一段分析、生成一个表格思路,这些事情已经比较常见,但当任务继续往后走,需要登录系统、读取业务数据、触发审批、写回结果、留下记录时,AI往往又退回到了建议者的位置,后续动作还是由人来搬运。 这也是很多企业觉得AI“好像有用,但又没有真正改变组织效率”的原因。AI已经能给出答案,Agent也开始具备规划和调用工具的能力,可企业内部的工作不是单点动作,而是一段有入口、有身份、有权限、有状态、有结果归档的流程。如果Agent只停留在个人侧,即使单个员工觉得效率提升明显,企业也很难把它当成一种可复用、可治理、可持续运营的能力。

By Ricky
金融机构如何把Agent接入内网流程:入口、执行、安全和审计的技术路径

金融机构如何把Agent接入内网流程:入口、执行、安全和审计的技术路径

梗概 分享一下金融机构如何把Agent接入内网流程时更现实的一条技术路径。 因为Agent不是普通聊天助手,它开始调用工具、访问文件和触发流程之后,问题会从模型层进入运行时层。K8s可以承载中心执行资源,但很难单独跟上Agent高频变化的执行粒度。更稳妥的做法,是在统一入口和基础设施之间补上一层Agent执行治理,把安全边界和审计证据放进每一次执行动作里。 Agent进入金融内网后,基础设施问题会被放大 金融机构对Agent的兴趣不难理解。投研人员希望减少资料整理时间,运营团队希望把重复流程自动化,研发和数据团队也希望让Agent承担一部分脚本处理和系统辅助工作。只要Agent还能停留在问答阶段,技术架构相对容易处理,企业主要关注模型接入、账号登录、数据出网和内容审核。 但Agent真正进入内网流程之后,问题会变得具体很多。它不只是生成一段文字,而是可能代表某个员工去读取内网文件,调用受控工具,触发审批流程,或者在受限环境里执行一段脚本。金融机构此时面对的已经不是“AI回答是否准确”,而是“这次执行是否符合权限边界,是否发生在受控环境里,是否能被追溯”。 这也是很多金融机

By Ricky
从聊天窗口到可交互界面:为什么MCP-UI会成为企业AI落地的关键一步

从聊天窗口到可交互界面:为什么MCP-UI会成为企业AI落地的关键一步

在CLI复出的当下,为什么MCP-UI仍然是大部分企业落地AI的最佳选择?如何基于FinClaw+MCP-UI构建一套输出企业自己的Agent体系~ 当Agent已经可以理解任务、调用工具并访问企业系统之后,员工到底应该通过什么方式和AI协作。 !在这里插入图片描述 很多企业最开始引入AI能力时,都会先做聊天窗口。员工输入问题,AI返回答案,这种形态足够轻,部署成本也不高,适合知识问答、材料起草和一些辅助分析类场景。早期试点阶段,这种方式确实能让员工快速感受到AI的价值,也方便IT团队控制使用范围。 随着Agent开始进入更具体的业务流程,聊天窗口的局限会慢慢显出来。企业里的很多任务并不是问一句、答一句就结束,员工往往还要确认业务字段,检查系统返回的结果,补充必要材料,再提交到某个流程里。纯文本对话可以解释任务,也可以给出建议,却很难把后续操作自然接到企业系统中,员工最后还是要切回原来的业务页面重新处理一遍。 一、聊天窗口适合问答,不一定适合承载业务操作 聊天窗口的优势在于自然。有了充分的普及,员工不用学习复杂界面,只要把问题描述出来,就能得到一个相对完整的回答。对于企业

By Ricky
员工很想用 VS 公司不敢用,这就是大部分公司AI落地的现状~

员工很想用 VS 公司不敢用,这就是大部分公司AI落地的现状~

梗概 员工很想用,企业不敢用是引入Agent时很常见的一种状态:员工已经开始把AI当成工作助手,企业管理侧却很难直接放开。问题不在于Agent是否好用,而在于它一旦开始执行任务,就会触碰权限、文件、网络和审计边界。今天分享一下,如何让企业在可管控的安全底座上引入各种Agent能力~ 大部分职场人已经感受到Agent的价值 现在很多职场人接受Agent的速度,比公司想象得快得多。因为现在Agent带来的体验不是“多一个聊天窗口”,而是让很多原来要在不同工具之间来回切换的工作,变成一次相对连续的交互。它能理解上下文,能把一段资料加工成可交付内容,也能在授权范围内调用工具完成一部分操作。对于一个具体岗位的人来说,只要结果可用,过程足够省事,这类工具就很容易被纳入日常工作习惯。 企业管理层面对这件事时,感受到的压力并不一样。员工看到的是效率,公司看到的是执行权被交给了一个新的软件形态。过去AI更多停留在问答和内容生成阶段,风险还比较容易被理解为“回答不准”或者“内容要校对”。Agent进入工作流后,风险会落到文件访问、命令执行、外部连接和工具调用这些更硬的环节上。它不是只在聊天框里输

By Ricky
如何为自己的企业构建一个Agent适配底座?CIO选型时真正要看的是什么

如何为自己的企业构建一个Agent适配底座?CIO选型时真正要看的是什么

当Agent开始调用工具、访问系统、执行任务、交付结果之后,企业到底应该如何承接这些能力,今天分享一下如何为企业构建一个Agent适配底座~ 今天分享一下企业在引入Agent能力时,一个很容易被忽略的问题:当Agent开始调用工具、访问系统、执行任务、交付结果之后,企业到底应该如何承接这些能力。 很多企业现在已经不缺AI工具。员工会用桌面Agent处理文件,研发团队会用Agent分析代码,不同的业务部门也可能自己接入一些面向客服、运营、数据分析的工具。单个场景看起来都能提升效率,但站在CIO或AI平台负责人的角度,真正需要判断的是:这些Agent进入企业之后,能不能被统一接入、统一运行、统一管控。 一、Agent适配底座到底是什么 Agent适配底座可以理解为企业内部承接各种Agent能力的一层基础设施。它负责把不同来源、不同形态、不同运行方式的Agent接入企业环境,让它们在同一套身份、权限、运行、安全和审计规则下工作。 CIO选型时,关注点要从“哪个Agent更聪明”,转向“企业有没有能力承接越来越多Agent带来的运行复杂度”。 视角个人Agent企业Agent

By Ricky
企业如何搭建一个底层架构来运行不同的Agent,确保AI运行的安全可控

企业如何搭建一个底层架构来运行不同的Agent,确保AI运行的安全可控

随着AI的发展,Agent一定是从通用Agent逐步细分出不同行业、不同领域能够完成不同任务的Agent,那对企业来说,也会引入更多的Agent,那如何做好Agent的管控会变得更重要,今天分享一下如何搭建一个Agent运行的底层架构,来保证Agent的安全可控的在企业内运行~ 今天分享一下企业引入多Agent时,一个更底层的问题:企业到底应该如何搭建一套运行架构,让不同类型的Agent可以在同一套环境里工作,同时把执行过程管住。 这件事在前期并不明显。一个员工打开某个Agent工具,让它整理材料、生成报告,只要结果可用,就不会追问太多底层问题。 当Agent进入企业之后,会服务不同部门,接入业务系统,处理权限不同的数据,还可能承担长周期任务。如果仍然把每个Agent当成独立助手来配置和运行,后面就会需要如何统筹管控的问题。 多Agent进入企业后,复杂度首先出现在运行层 很多团队最初讨论多Agent,会把注意力放在“谁负责规划、谁负责执行、谁负责复核”这类协作关系上。这个讨论有价值,但如果落到企业系统里,协作只是上层表现,真正先暴露出来的是运行层复杂度。 不同Agent

By Ricky
从个人使用到企业托管:FinSafe如何让桌面Agent进入统一管控?

从个人使用到企业托管:FinSafe如何让桌面Agent进入统一管控?

企业引入AI工具,过去更多是在管账号、费用、模型选择和数据合规。 但桌面Agent进入企业之后,问题会变得更具体。员工在本机运行一个Agent,它可能读取文件、调用命令行、执行脚本、访问内部系统,也可能把这些动作串成一个自动化流程。 对个人来说,这是效率工具;对企业来说,它已经带上了一部分执行权。 当AI开始“做事”,企业要管的就不只是“谁在用AI”,还包括它运行在哪台设备上、使用哪套策略、访问过哪些目录、调用过哪些工具、哪些动作被允许、哪些动作被拒绝。 如果这些问题说不清,AI使用看起来在快速扩散,实际边界却可能分散在每个人的电脑里。 企业AI管理,正在从账号管理走向执行管理 过去企业管理AI,重点通常放在入口侧。 谁能登录模型平台,哪些团队可以使用企业知识库,哪些数据不能外发,哪些模型供应商可以接入。这些问题都很重要,但它们主要处理的是“使用入口”。 Agent带来的变化在于,它不只回答问题,还会替用户执行动作。 一个桌面Agent可能读取项目目录,运行一段脚本,调用内部接口,生成并修改文件,也可能在用户授权后连接更多工具。它的价值来自能执行任务,风险也来自能执

By Ricky