风起云涌的AI技术圈

近来harness概念越来越流行，大家也越来越意识到LLM自身局限性：LLM不是包办一切的万能助手，而是一个极其聪明但又没那么可控的kernal

为了增强LLM的可控性，诞生了很多Agent开发工具，比如LangFlow，LangGraph，Dify，Coze等，我基本上也都体验了一下，其中深度体验了LangFlow和LangGraph，在现代化AI加持的华丽包装下，有种非常诡异，割裂的感觉：它们还是在用传统软件工程的方案来为LLM打造一套高达机甲。具体来说：

  • 极其厚重，冗长的开发流程和代码耦合，导致很难让AI辅助开发，一步错，步步错
    • 节点架构固定，很难用完全拓展包的形式接入workspace，所以不得不污染原仓库，导致很难跟进官方更新
    • 想自定义节点，自定义flow基本上要让AI通读一遍架构，然后才能开始，而且后面还有无数易出错的步骤等着我们
  • BUG极多，点名批评LangGraph和LangFlow，撤消重做，Flow版本控制都是纯代码堆砌+补丁，合理怀疑是AI编程刚起步时代的产物
    • LangFlow的flow变更后，整个前端巨卡无比，原因是每次变更都是全量的dump+状态冗余，迭代多了直接动都动不了
  • Debug流程不友好，LLM本身不可控，所以需要非常完善的Debug工具支持，才能不断微调到满意的程度
    • 这点LangFlow做的还行，毕竟本身节点级的log输出对BUG排查还是比较友好的
    • 点名批评LangGraph，官方推荐的Studio根本不是人类能理解的工具集
  • 热更新支持不友好，可以预见的是，一个flow从初版到终版需要迭代非常多次，所以修改代码，配置之后无感热更是重中之重
    • LangFlow的超重量级重启，节点参数改变就需要2-3分钟的重启才能看到效果，这在2026年的今天简直无比抽象

还有很多小的槽点就不在此赘述了，用了几个月之后，总结了这些痛点，我也开始思考一个AI原生蓝图到底需要具备哪些能力，所以就有了这个项目：AI Native Flow

AI Native Flow介绍

AI Native Flow是我个人对harness理解和蓝图开发经验的结晶，也是我认为的开往新时代的航母，它具备以下特性：

  • 完全基于ts，秒级完整服务重启，原生支持并发执行
  • 完全节点化的设计思想，万物皆节点，拓展友好
  • 完整的artifact机制，可以做到不重启热更配置和逻辑
  • 完全轻量化架构，整个仓库代码量极少，结构清晰，运行时完整，LLM可以清晰，完整的理解项目架构，以精准，稳定的姿态输出自定义node和flow
    • 提供完整的dump机制，AI Coding工具不直接输出flow json文件，而是通过写代码的方式，从内存dump出最终json，最大程度减少出错的可能性，也尽可能让AI宝贵上下文用在逻辑处理上
  • 完全前后端分离，可只启动后端，最小化性能占用，也提供类似蓝图的前端编辑器，用于编辑和Debug
  • 完整的拓展包支持，可以像在Claude Code接入skill一样接入一个全新的拓展包，对原仓库零污染
  • 完善的第三方调用支持，http服务，cli sdk，mcp，可以方便接入任意环境中
  • 完善的Debug工具集，支持逐节点模拟输入，Debug
  • 支持flow之间互相调用（对标Agent群互相调用），在保证上下文精确的前提下，解放LLM的发散潜力

那么，愿景呢？

野望

LLM大爆发的当下，我仍然推荐在初期使用Skills来快速验证流程，原因有二：

  • 虽然他有很多缺点，但他真的很快，成型快，迭代快
  • 随着LLM不断进化，一些必要的harness流程组件会慢慢变成枷锁，所以保留这个Skills原型是静观其变的神之一手
    等Skill足够固化，稳定之后，开始转为flow
    经常让AI总结Skills的朋友想必都体验过以下抓狂时刻：
  • 明明一个非常重要的步骤，但是LLM就是时不时的不听话，忘记执行
  • 一个复杂的流程Skill，哪怕拆分了多份说明文件，依旧难以保证LLM完全按照预想的流程执行，导致无法完全，稳定交付成果
    其实Agent的开发就是把Skill的一些固定流程代码化，把需要发散的地方继续交给LLM，既保证了稳定性，又节省了Token

那么答案就很简单了，我们可以在AI Native Flow里实现一个通用的，转换Skills的flow，这个flow专门用于限定AI如何将Skills转换为flow，从而最大化控制流程的稳定性