- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
为什么要做 FylloCode？
我从去年春天开始逐渐放弃古法编程，尝试拥抱新的变化 —— Vibe Coding。确实，Vibe 起来很令人着迷，它大大降低了行业门槛，能让这项专业技术变得唾手可得。但是作为企业级应用的开发，它还远远不够。最近一段时间，我一直在考虑我们这个行业的未来，以及我们这群从业者作为漩涡正中心未来该何去何从。
我们是不是要被 LLM 替代了？我们这么多年积攒的工作经验难道全部白费了么？Coding Agent 真的接手现实中的 Coding 工作后，行业是否会因为没有新生代血液的注入发生断档？后来我突然想明白了这件事，我们目前所经历的时代，就像前些年由移动互联网推动的新媒体时代，人人都是自媒体，但是专业的记者依然有更大的舞台。岗位不会消失，只是入行门槛变得更低。而我们作为专业从业者，其实没有被替代，只是在新技术的推动下，给我们提出了更高的要求。
就像摄影师，我们每个人都有手机，各厂商号称几亿像素，加上各种修图软件，人人都是摄影师。但是摄影也有技术好坏，当我们需要专业场景的拍摄需求时，还是会主动去找专业的摄影师。
所以新的时代下，对我们的要求也更高了，真正需要我们处理的不再是重复的 Coding 工作，而是更高层级的业务理解、架构设计。行业也不会断档，虽然入行门槛低了，但是未来对于成为专业程序员的要求也会更高，要有更好的大局观和架构理念。新生代的程序员们想要变得专业，依然要通过一步一步的学习、摸索，掌握各种设计模式，才能成长为专业的程序员。
所以针对这些考虑，我开发了 FylloCode，把 Vibe Coding 变成 Agentic Coding。
未来我们的工作，更多的是接触业务，考虑架构设计，做好 Proposal 后，审查 Proposal，一边自动编码实现，一边考虑下一个 Proposal。
FylloCode 有哪些功能？
FylloCode 不是"又一个 Coding Agent"，它是对 Coding Agent 的增强。为了方便跟当前的 Coding Agent 做集成，采用 ACP 协议对接，所以只要你电脑上安装着 Coding Agent，并且它支持 ACP，就可以直接使用。
回顾了我的日常工作之后，发现一般可以分为三个大的阶段：任务规划 → 任务实现 → 任务总结。在调研了市面上诸多工作流后，我发现 OpenSpec 很符合这个想法，而且它还提供了很多扩展点。因此 FylloCode 直接内置 OpenSpec 作为基础工作流。
总的来讲，FylloCode 有以下几个核心功能：
- 基于 OpenSpec 的三阶段流程（Proposal - Apply - Archive），且支持扩展
- Proposal 阶段中，FylloCode 会引导你把不清晰的需求逐步收拢为一份合理的 Proposal（比原版 OpenSpec 的 artifacts 更加清晰）
- Apply 阶段，按照 Proposal artifacts 落地开发
- Archive 阶段，归档、提交，并合并回 main worktree
- 默认在 linked worktree 中进行工作，支持多个 linked worktree 并行开发
- 支持多聊天消息并行、多 Proposal 的 Apply 并行
- 受够了每天打开多个 terminal，一个跑 Claude Code，一个跑 Codex，还有 Kimi 和 Qoder，所以希望有一个统一的界面来驱动这些 Agent。后来发现了 ACP 协议，于是 FylloCode 以 ACP 协议驱动本地 Coding Agent。目前 ACP Registry 中已经支持了 35 款 Agent
- 支持自定义 workflow，可以通过多 stage 的工程化 workflow 驱动多个单 Agent。企业级应用开发不应该是黑盒。其实在 Workflow 的选择上，我还考虑了挺久，大体上有三个方向：
- 主 Agent 驱动多个子 Agent：考虑到 FylloCode 目前通过 ACP 与本地 Agent 通信，目前还不支持这种方式。而且现在市面上的子 Agent 一般还是负责单一的任务，比如代码库探索，用完即销毁。如果有问题的话，没办法第二次与子 Agent 通信。
- Agent Teams：我觉得目前阶段看起来，Teams 更适合完全没有头绪的时候，给 Teams 一个命题，让它们直接产出一个结果。但是企业应用不应该是黑盒，每一个功能我们都需要仔细考虑之后再做实现
- 工程化方式以Workflow驱动多个单 Agent：这个是 FylloCode 最终选择的方案，它有几个好处
- 避免共享上下文，导致任务偏移，一错再错。因为每一个 Proposal 都是我们与 Agent 沟通后确定好的方案，所有 Agent 应该以 Proposal 为准
- 避免单一 Agent 同质化偏差，可以在 workflow 中每个 stage 使用不用的 Agent，避免 Agent 的 Harness 约束问题导致错误
- 避免单一模型同质化偏差，可以在 workflow 中每个 stage 使用不同的模型，避免由于模型训练预料的问题导致错误
- 多系统任务集成，目前已经支持本地任务和云效任务，未来会逐步集成更多任务平台。读取任务后，可以直接发起聊天，直到它成为合格的 Proposal
- 可能有佬友会对这种 API 方式集成有疑问，为什么不提供 skill，让 Agent 自动读取、自动执行。我的想法是我们穷哥们的 token 真的耗不起，API 集成速度快，而且不耗 token，好 token 要用在刀刃上
- 任务看板目前已经集成云效
- 定时任务即将上线
- 将工程规范沉淀为 guidelines，并在工作流中自动持续维护，无需人工干预
- guidelines 是软约束，Agent 不一定完全遵守，所以 FylloCode 的健康检查会建立工程层面的硬约束（lint、test runner、git hooks、CI）
- 内置两个 MCP Server（由于 ACP 当前只有 MCP 形成了通用标准，所以 ACP 目前只提供了这种稳定增强的实现）
- fyllo-specs：内置 OpenSpec，结合 linked worktree 管理
- fyllo-skills：内置 guidelines tool
未来的规划
FylloCode 的目标是提供一款专业的、适合企业应用的 Coding 工具，未来有以下一些方向的考虑
- 更多的 ACP Agent 控制，以及资源管理
- 集成更多企业内部工作流程
- 多人协作流程
- 数据多端同步
- ACP 驱动云端 Agent，不依赖本地
放一些截图
7 个帖子 - 3 位参与者