对话「非与智能」创始人柳钢：创业三个月拿下两轮融资，我想让企业真正拥有自己的AI

最近，AI 初创公司「非与智能」连续完成了种子轮与天使轮融资，金额累计超千万美元。其中，天使轮投资由锦秋基金与香港高才创业投资基金共同领投。

这则融资消息，在被 Personal Agent、消费级机器人覆盖的 AI 领域显得有些不同 —— 这家公司面向的是 To B 市场，要做的，是帮企业构建全栈、私有化的智能体平台。

它的创始人兼 CEO 柳钢，不少关注 To B 的朋友可能不陌生。

他的上一段职业经历，是在“GitLab 中国” 极狐GitLab 担任 CEO。几年前，这家公司曾单轮融资过亿元。再往前，柳钢曾是商汤科技集团首位副总裁，从最早期开始帮商汤构建商业化体系，也在 Oracle、微软、SAP 等全球科技企业做过高管。

这些经历，多少能解释为什么「非与智能」选择企业级 AI 市场。

但这只是原因之一。

柳钢告诉我，自己在 2026 年春节前后下定决心创业。那时，模型、推理引擎和算力都在变化，智能体也开始从回答问题走向执行工作。

在他看来，这会改变企业的 AI 需求：过去两年，企业关心的是 AI 怎么接入业务系统、怎么衡量实际价值。接下来，企业要的是把智能变成自己能持续运营的能力。

这背后还隐藏着一个更具体的需求：企业要在有限的预算和算力条件下，做出好用、可控且高性价比的完整 AI 系统。这正是如今「非与智能」想帮客户做到的。

冲着这个创业目标，我了解到「非与智能」设计了一套全栈方案，从算力底座到推理操作系统，再到企业智能体。

一家初创公司，为什么一上来就要从从 Infra 做到应用层？和市面上不少服务 B 端的 AI 公司相比，这个切入范围显得很大。

柳钢的解释是，智能体承担的任务越来越复杂，推理效率、执行可靠性和运行成本需要放在同一套体系里解决，工作经验也应该在持续使用中留在企业内部。

举个更细节的例子，一起做三层架构，上层应用产生的工作流会反过来促进推理优化。

上下文有多长、什么时候并发升高、哪些内容被反复读取、哪一步出现等待或重试，这些细节都会影响系统如何组合模型、管理缓存和显存，以及是否需要调整推理框架或硬件配置。把三层放在一起设计，团队就能根据实际任务做这些优化。

在这个产品理念下，「非与智能」现在已经在软件研发场景获得了愿意为全栈产品付费的客户。

在公司成立的第一个季度，就有企业客户采购了全套企业智能体平台，并在使用一个月后追加了采购。

柳钢透露，产品进入真实研发流程后，这家客户的智能体日均 Token 调用量在两个月内增至原来的 5 倍，连续 30 天区间活跃率达 92.5%。

关于这套产品如何落地的更多信息，以及柳钢对 AI To B 市场的思考，在以下我们的对话中，欢迎围观。

做To B，为什么要从算力做到应用？

Q：「非与智能」成立于2026年中旬，为什么选择在这个时间点再次创业？

柳钢：我是在 2026 年春节前后决定创业的。那时模型、推理引擎和算力都在变化，智能体也开始从回答问题走向执行工作。

我一直在想，能不能让企业用上足够先进的智能，同时掌握数据、安全、模型选择和长期积累的能力。私有化是实现这一目标的重要方式，但不是把云端系统原样搬进机房。

真正难的是，在企业有限的预算和算力条件下，做出好用、可控且经济的完整系统。

Q：今年 AI 的能力有很大提升。与前两年相比，你觉得企业的 AI 需求和痛点发生了哪些变化？

柳钢：回看我接触的企业，2023 年大家首先想知道大模型能做什么，随后两年，知识库、办公和研发试点多了，问题逐渐变成怎样接入业务系统、怎样衡量实际价值。

到 2026 年，智能体能连续执行任务，企业开始认真计算长期使用的账：数据留在哪里，谁能授权，模型更新后知识和流程能否留下，扩大使用后成本能否承受。

行业节奏各不相同，但现在企业已经不只是在采购一个 AI 工具，而是在考虑怎样把智能变成自己可持续运营的能力。

Q：这些企业需求，可以解释你为什么选择这个方向。但为什么「非与智能」一开始就同时做应用、平台和推理优化？会不会战线过长？

柳钢：我们选择全栈，是因为企业最终要检验的，是一项工作能否安全、可靠、经济地完成。

应用层让智能体进入具体任务：我们的 Firmior Code 从软件研发切入，Firmior Work 拓展知识工作，Firmior Expert 面向企业高管与核心岗位。

至于 OS，我们的 Firmior OS 承载各场景共同需要的企业记忆、知识技能、工作流、模型编排与安全治理。

还有我们的推理优化和 FEAS（Firmior Enterprise Agentic Server，面向企业智能体推理与运行的一体化服务器系统），为复杂任务的持续运行提供性能与算力支撑。

底层、平台与应用相互协同，企业才能在使用中不断积累自己的智能。

全栈也不意味着每一层要同时、等量铺开。我们会由真实任务决定投入顺序，逐步沉淀跨场景复用的能力，还要以客户使用、任务可靠性和单位成本检验每一步。

Q：能不能用一个案例，把三层架构的作用以及三层统一架构的优势讲清楚。

柳钢：以一个典型缺陷修复任务为例。员工提出目标后，Firmior Code 会读取获授权的代码和相关上下文，规划修改、调用工具、运行测试，最后交给工程师审查。

Firmior OS 管理仓库权限、工具调用、人工确认和任务记录，也把经过验证的工程规范沉淀下来。底层则根据这类任务的上下文长度、调用峰值和等待时间，调整模型组合、缓存、推理引擎与硬件资源。

三层放在一起，目的不只是让代码改出来，还要让任务在企业规则内完成，并让下一次同类工作做得更好。

如果做个总结，就是应用让我们看见真实工作，而 Firmior OS 沉淀跨场景的记忆、知识技能、工作流与治理能力，推理优化和 FEAS 回应复杂任务的性能与承载需求。

Q：一起做三层架构，上层应用产生的工作流也能影响到底层推理优化的效果？

柳钢：是的。还是以编程智能体为例，它接到任务后会读取代码、分析上下文、调用测试，再根据结果继续修改。

因为应用和推理系统由我们一起设计，我们能看到真实负载：上下文多长、什么时候并发升高、哪些内容被反复读取、哪一步等待或重试。随后才决定用什么模型组合，怎样管理缓存和显存，是否要调整推理框架或硬件配置。

优化不能只看每秒输出多少 Token，还要看任务能否完成、员工是否愿意持续使用，以及在同等使用规模下的总成本。

Q：这套三层架构目前的完成度如何？哪些模块已经上线或相对成熟，哪些还在规划中？

柳钢：可以先从客户已经用起来的部分讲。

Firmior Code 已在客户的私有环境里进入真实研发流程，已经有客户付费采购使用后又增购；Firmior Work 面向知识办公、研究分析和成果交付，是我们同步推进的应用方向。Firmior OS 承载模型编排、权限治理、记忆、知识技能与工作流，FEAS 则是企业侧的算力承载形态。

现阶段，我们主要把模型、推理引擎和标准服务器调到最好，让应用真正好用。还有，自进化机制和更深入的硬件设计会随着使用继续推进。

另外，Firmior Expert 面向专业岗位，我们也在按真实任务逐步展开。

让企业客户付费又续购的策略是什么？

Q：实际落地时，可能并非所有企业都会一次性采购全栈产品。目前客户对哪些功能或产品最感兴趣？

柳钢：已验证的付费场景是软件研发，但我们的产品并不只面向研发部门。企业也会从办公、研究、分析等日常任务理解 Firmior Work 的价值。

我的思路是先提供足够标准、上手就有价值的应用，再让企业按自己的规模和约束配置 Firmior OS、模型与算力，而不是每个客户重新定制一套系统。

客户可以从一项值得解决的任务和少量使用者开始，看到效果再扩展；这种渐进采用，也要求底层平台能承接更多用户和场景。

Q：不少公司已经有 Coding 和 Work 智能体，其中一些还是自研的。Firmior Code 和 Firmior Work 准备怎样打开局面？

柳钢：我们不会要求客户先推倒已有的 Coding、办公工具或业务系统。真正能打开局面的，是一个上手就能解决问题的产品。

Firmior Code 和 Firmior Work 尽量把高频任务做成可复用、易采用的能力，而不是每进一家企业就重做一套。用户看到的是熟悉的编程或办公体验；企业得到的，则是部署在自己环境里的模型、推理、权限和知识积累。

先让一个团队自然地用起来、看到价值，再逐步扩展到更多岗位，比先做大规模改造更符合企业实际。

Q：从代码场景扩展到 Firmior Work，哪些能力可以直接复用？

柳钢：研发与知识工作的任务不同，但在我们看来，都需要清晰的身份与权限、可信的知识来源、可执行的工作流和可追溯的结果。这些共性能力由 Firmior OS 承载。

进入 Firmior Work 后，我们还会依据文档、沟通和跨系统协作的真实场景独立打磨产品，不能简单复制研发场景的形态。

Q：刚才提到，非与智能已经有付费客户了？

柳钢：是的，公司成立首个季度，就有企业客户对全套平台的付费采购，还在实际使用一个月后追加了采购。

Q：客户追加的具体是什么？是算力资源还是智能体账号，还是其他？

柳钢：这里的首购不是只开几个账号。客户是先采购了一台搭载模型、推理系统和编程智能体的企业侧服务器，能在自己的环境里直接使用；实际使用后，又追加了同类设备。

到这次采访时，部署已经扩至多台。

我觉得这个客户的采购过程很有代表性。他先看产品能不能用、账算不算得过来，再决定扩大使用。我们也希望客户是因为真实工作中的效果而继续增购。

Q：这个客户刚开始的使用效果是怎样的？

柳钢：我说一组数据吧。

这套产品进入客户的真实研发流程后，连续 30 天区间活跃率达到 92.5%，智能体的日均 Token 调用量在两个月内增到了原来的 5 倍。客户的使用不断加深，这些真实反馈也会持续推动产品迭代。

当然了，产品体验是一方面，能让客户复购，背后还有模型、推理、系统和标准硬件的协同。这些能让客户在有限预算内扩大使用。

Q：我们具体能提升多少性能和成本效率，有没有数据或案例？

柳钢：现在已有的客户部署说明，我们在标准 GPU 服务器和有限算力条件下，也能支撑很多研发人员使用先进的编程智能体。

这个客户从首购到增购，说明他把体验和成本都算过了。但不同模型、硬件、并发和任务会带来不同结果，我不会用一个倍数概括所有部署。

真正有意义的比较，是在说清配置、用户规模和使用周期之后，看任务质量、响应速度与总体拥有成本。

我有信心我们团队的推理优化技术能力及整体方案的性价比在国内应该是属于第一梯队。

做好这件事是有门槛的。因为企业不能无限增加 GPU、预算和运维人手，云端的大规模部署经验也不能直接照搬。

在实际工作中，我们要先看智能体实际在做什么：上下文有多长、什么时候出现峰值、哪些步骤需要强模型、哪些任务反复读取相同信息。再回到模型组合与量化、推理引擎的算子和缓存、显存与内存调度、标准服务器配置上联合优化。

智能体、推理和硬件团队在同一套目标下工作，技术指标最终要落到客户能完成多少任务、体验是否稳定，以及长期使用是否划算。

Q：什么样的任务链最能放大推理成本和系统不稳定？非与会用哪些指标判断优化是否真正有效？

柳钢：我们会重点看需要多轮规划、跨系统调用和结果校验的任务，它们更容易暴露延迟、失败恢复与成本之间的相互牵动。

评价优化时，也不能只看 Token 吞吐或单次模型响应，还看完整任务的完成质量、耗时、人工接管与单位成本。对外比较性能时，要确保任务组成和统计基线可比。

最大的护城河，以及一年后的目标

Q：市面上有不少公司服务于B端的AI需求。有的做企业智能体，有的做算力配置、推理加速，有的在后训练模型。总结来看，你觉得非与在这个市场中的独特之处是什么？

柳钢：我们的独特之处，是从企业真实任务反推整套系统。很多公司擅长其中一层；我们把智能体、模型选择、推理引擎和标准硬件放在一起优化，尤其要解决预算、算力和安全边界同时存在时的问题。

现在我们使用可采购的标准服务器，把更多精力放在 Firmior OS、推理和应用的协同上。等到业务规模与技术积累足够，我们会再考虑更深入的硬件设计。

首个客户从采购到增购、再到持续增加使用，我觉得这已经说明，这条路线已经在真实工作中得到检验。

Q：目前非与主打的客户画像是怎样的？客户画像之后会发生变化吗？

柳钢：我不会先用人数或行业把客户划得很窄。

更重要的是，企业是否有值得交给智能体的高频任务，是否在乎数据与知识留在自己手里，以及能否从实际使用中看到回报。

我觉得研发、办公和专业岗位都可能成为入口，可以先让一个小团队用起来，逐步扩展到更多人和场景。对数据治理还不够完善的企业，我们也不希望把大规模清洗和流程重建当作使用产品的前提。

先解决具体问题，再随着使用沉淀知识和工作方法，采用过程应该尽量自然才对。

Q：非与的商业模式最终更像软件订阅、许可、推理服务还是软硬一体？

柳钢：我们的商业模式与平台三层架构相对应：Firmior Code、Firmior Work 等应用按席位年度订阅；Firmior OS 作为共享平台层一次性收费，并按部署规模计费；FEAS 服务器按硬件选型单独报价。

客户可以根据使用场景和既有基础设施按需组合。平台层部署后可由不同智能体共享，推理优化则持续改善专属算力的使用效率和单位任务成本。

Q：未来一年，你觉得AI TO B市场会发生哪些变化？你希望一年后非与智能达成怎样的目标？

柳钢：未来一年，我觉得企业会更认真地算两笔账：一笔是眼前的任务能否完成、成本是否合理；另一笔是用了半年、一年之后，知识、流程和模型选择权有没有留在自己手里。

对非与智能，我希望更多客户能从编程、办公和专业岗位中的具体任务开始使用，在同一平台上逐步扩大规模。

我们会继续把模型、推理和硬件协同做深，也推进 Firmior OS 的记忆与自进化能力。理想的结果是，企业从第一天就获得价值，往后每一次使用，又让这套属于自己的智能更懂业务。