在本地部署了一套超轻量的 Agent 工作流工具

这周四，和我们 CTO 一起，给老领导公司部署了一套 Agent 工作流系统。相当有成就感，也算是回报恩情。

我毕业之后其实只待过一家公司，然后就出来创业了。当时的领导是东北人，30 多岁，人很 Nice。

有次北京拆隔断，我晚上下班回来发现家没了。一时租不到房子，大半夜的，领导开车过来帮我把东西拉到他家，让我暂住。

是个善良的人。

后来，我离职创业。老领导则自己开了一家外包公司，主要给政府做一些项目。

上周，我写了篇 Agent 工作流的文章，领导微信找我说，他们也想用类似的产品提升效率，但碍于公司的业务，只能本地部署。求助我帮忙。

我当时根本没犹豫就回复他，我来帮忙搞定。

私有化部署，必然是需要借助开源项目了。领导公司不大，肯定是买不起厂商的私有化服务。

现在，其实 Agent 工作流的项目也不少，Coze、n8n、Dify、JoyAgent、Astron Agent，可选项非常多。

这些项目各有千秋，比如 Coze、n8n、Dify 的 C 端基础都比较好，生态相对丰富。JoyAgent、Astron Agent 则是面对严肃场景，而且是 Java 体系。

最开始，我们 CTO 计划选择 Coze，但查了下，Coze 整个项目还是比较大，而且后端是 Golang 编写的。我考虑了下，估计后续维护和开发对于中小团队来说比较吃力。

各种权衡之后，我们选择了科大讯飞的 Astron Agent。主要原因有两个：

第一，它足够轻量。

Astron Agent 整体架构非常干净，没有太多花哨的模块，也没有臃肿的前后端通信逻辑。

对于资源有限、又没专职运维的中小公司来说，这种轻量化带来的成本优势太明显了。

第二，技术栈是 Java + Spring Boot，这对传统企业太友好了。

老领导公司的项目几乎都是 Java 写的，后端团队对 Spring Boot 非常熟悉，这意味着他们可以自己维护、改造、甚至深度定制。

先放下这个项目的 GitHub 地址：

https://github.com/iflytek/astron-agent

其实安装非常简单。官方提供了一份详细的部署指南，我同样贴过来：

https://github.com/iflytek/astron-agent/blob/main/docs/DEPLOYMENT_GUIDE_zh.md

我们那天部署，其实挺顺的。整套系统跑起来大概分三步：先装 Casdoor，再装 RagFlow，最后再装 Astron Agent 核心服务。

Casdoor 是用来做身份认证和单点登录的，本身是一个非常成熟的第三方开源项目，它相当于整个系统的门卫。

所有人要登录、要访问任务面板，都得先通过它验证。好处是，用户只登录一次，后面所有模块都能直接用，不用每个子系统都重新注册账号。

RagFlow 是另一个知名的开源项目，主要做检索增强生成，也就是 RAG。

简单说，它能让系统在执行任务时，先查资料再输出结果，不是凭空生成。毕竟企业内，其实有很多的私有文档。这部分大家肯定很熟了，我不过多解释。

不过，安装 RagFlow 是可选的。如果不想安装，也可以使用讯飞提供的星火 RAG 云服务。查了下，目前还不支持其他平台的 RAG 云服务。

Casdoor 和 RagFlow 安装完毕后，再启动 astronAgent 的服务就可以了。

这过程中，主要做的事情就是配置环境变量，同时注意端口号没被占用就行。都支持 Docker 部署，所以，我觉得没什么难度了。我们 CTO，前后花了 15 分钟时间，就搞定了。

说下整体的系统配置。如果不装 RagFlow 的话，那 2 核、4G 内存、50G 硬盘的系统就够了。如果要装 RagFlow，那需要 4 核 16G。

注意啊，这都是部署基本的 Java 或者 Go 项目，所以 CPU 就行，不需要 GPU。一会我们会说，模型在后台是可以调用云端的。

下面这是 Casdoor 的页面。我们需要在 Casdoor 里把应用绑定到组织里， 并且填上项目的回调地址。

其实就是单点登录么，要告诉系统，哪个用户可以登录哪些应用。

下面是 RAGFlow 的截图。点击头像，可以在 Model Providers 那里添加模型，因为做 RAG 嘛，肯定需要用到 Embedding，这里只要按照说明配置就好了，都不复杂。

下面这是登录 Astron Agent 后的页面。玩了下，功能完备度还是挺高的，有插件、MCP、RPA， 还支持添加自己喜欢的模型。

创建智能体部分，可以通过提示词创建，或者工作流创建。

提示词创建我就不演示了。这事儿过于简单。当然，简单不是说没用啊。

我那天装完之后，其实花了一个小时时间，和领导公司的同事们交流，我发现很多人的需求，基本都可以通过第一种创建方式解决。

比如有位项目经理说，她们每个项目都会涉及到大量的文档，比如需求文档、设计文档、会议纪要、QA 文档，他们和国企合作，人家对文档的要求非常高。

但文档写了之后，大家利用率很低，毕竟没人愿意没事读那些长篇累牍的内容。

我说这很简单，你就给每个项目做一个 Agent，然后把文档都放到知识库里，然后再输入简单的提示词，就可以做成 XX 项目助手的 Agent。非常简单。

这部分我不再赘述。咱们主要看看工作流 Agent 的创建。毕竟公司里，稍微复杂一点的事情，都需要依赖工作流。类似 Agent 产品的核心竞争力也是工作流部分是否好用，易用。

咱们开始。先选择工作流创建。

紧接着，进入到熟悉的画布，也就是工作流编排页面。左边可以选节点和工具，拖拽到右侧画布，然后连接形成工作流。

我给大家分享工作流创建时，花了一些时间讲编程中函数的概念。

其实节点就像是函数，有输入，然后有输出。A 节点的输出，可能是 B 节点的输入。只要大家理解了这一点，就能够明白节点里为什么有参数之类的选项（对于非工程师来说，确实需要理解）。

如果大家对 Workflow 还是没有什么概念，那我推荐 LangChain 官方的一个文档。

图文并茂，写得非常清楚。它总结了五个常见的 Workflow 工作流，包括提示链工作流、并行工作流、路由工作流、编排器工作流评估器-优化器工作流。

https://docs.langchain.com/oss/python/langgraph/workflows-agents

比如下面这个就是路由工作流的示意图，核心就是根据输入对任务进行分类，然后进入到不同的工作流中处理对应的任务。

咱们继续实操。我在画布中，把大模型的工作流拖拽进来。

紧接着，再把开始和刚刚的大模型节点连接起来。注意看右侧，我选择了 GLM-4.6 模型，这个可以在模型管理那里配置，点新建模型，输入 API 密钥、接口地址等信息后就可以添加。

但注意，模型 API 必须支持 OpenAPI 格式。我下午折腾时，本来想用 MiniMax 刚发布的 M2 模型，但折腾半天发现它居然还不支持 OpenAPI。所以后来选了智谱。

我帮他们做了一个翻译英文文章，并从中按照我的要求总结关键信息的 Agent。

第一步，请大模型按照我的要求翻译内容。第二步，再用我要求的格式和风格总结内容。第三步，输出。

当然，如果不想麻烦，也可以导入别人做好的工作流。其实就是一个 YML 文件。我把我的模板放到 GitHub 上了：

https://github.com/aying20/aitranslator

从进他们公司部署，到我给大家分享经验，前后差不多两个多小时。

领导公司的同事大多是工作两三年的年轻人，日常主要就是接需求、改代码、交付项目，说白了，就是典型的外包模式。

我们聊完 Agent 平台，也顺势聊了很多 AI 的事。那种感觉挺强烈的。现在真的是到了每个人都该去想，怎么把 AI 用起来的时候。尤其在他们这种场景下，AI 能做的地方太多了。

对接政府、对接国企，文档一堆又一堆，代码呢，多是增删改查的活。

这种地方，AI 一上，提效空间能大得吓人。

忙完已经晚上七点多，北京天早就黑了。我开车往家走，路过北四环的银谷大厦，一瞬间有点恍惚。

十多年前，我和老领导就在那栋楼里共事。那会儿我刚毕业，每天看着楼下车水马龙，觉得自己正要开始一段新的生活。

今晚又从那里路过，好像那种感觉，又回来了。

能帮老领导这忙，我挺开心的。 AI 工作流这件事肯定还会越变越好，但那天晚上我更在意的，是能再和那些熟悉的人，一起折腾点有意思的东西。

文章来自于微信公众号 “AI产品阿颖”，作者 “AI产品阿颖”