fountain 多智能体事件驱动协作机制详解:fcoder 的 agent 与 event 全流程编排

📅 发布时间:2026/10/15 18:34:23
fountain 多智能体事件驱动协作机制详解:fcoder 的 agent 与 event 全流程编排
后端Web框架【免费下载链接】fountain一个用于服务器应用开发的综合工具库。 - 零配置文件 - 环境变量和命令行参数配置 - 约定优于配置 - 深刻利用仓颉语言特性 - 只需要开发动态链接库fboot负责加载、初始化并运行 - 覆盖服务器应用开发的各种场景项目地址https://gitcode.com/Cangjie-SIG/fountain点击查看免费下载fcoder 是 fountain 项目中一款命令行下的人工智能编程工具它用「智能体Agent 事件Event」的模型把软件工程全流程拆解为一条可编排的流水线。agentevent.md 是这套机制的核心定义文件它用一张对照表明确了 13 个智能体各自的职责边界、接收事件与返回事件。阅读本文后你将掌握 fcoder 的事件流转规则、智能体编排方式以及如何结合数据库结构与源码理解并扩展这套多智能体协作体系。事件驱动模型智能体是节点事件是数据技能是边在 fcoder 中一次软件开发任务不是由单个大模型从头到尾完成的而是被拆解为一系列事件Event由不同的**智能体Agent**接力处理。理解这三层关系是掌握整个体系的前提相关说明详见 fcoder/README.md智能体是流程的节点。执行一次流程时一个智能体可能多次接收不同的事件并使用不同的技能处理事件是沿着技能边在各个智能体节点之间流转的数据。事件名是智能体之间通信的“协议”一个智能体只处理它能接收的事件技能Skill是流程的边是原子化的只做一件事。一个技能只能处理一个确定的事件并返回一个由所执行函数确定的事件或由大模型直接返回的事件。正是因为有了这张事件表智能体的实现可以做到高度通用智能体的代码不需要关心当前正在处理什么事件也不需要关心该由哪个技能处理它只需要按固定循环执行按照事件查询技能把事件和技能包装为大模型访问参数按照大模型返回的 JSON 去执行函数按照函数返回结果构造事件、返回事件。这样做的好处很直接省去了让大模型判断“该用哪个技能、调用哪个函数”所消耗的 tokens也不必为每个智能体编写技能列表和选择逻辑的提示词同时由于智能体通过函数执行功能而不是直接执行命令可以在函数层做参数检查、误删保护等边界处理提升安全性。智能体与事件完整对照表agentevent.md 以一张表格完整定义了各智能体的职责。下表为原文的完整内容表中事件名为系统内定义的专有名词保留原文其中CodeCommiitter、CodeCommitation为原文定义写法配置时需保持一致Agent智能体接收事件Accept发送事件SendSupervisorStart, SpecReview, CodeReviewRequirements, FeasibilityReview, FeasibilityReport, RequirementReview, RequirementSpec, PreliminaryReview, PreliminarySpec, DetailReview, DetailSpec, CodeSpec, CodeCommitation, ToCommitAnalystRequirementsFeasibilityPreviewFeasibilityReviewerFeasibilityPreviewSpecReviewProductManagerFeasibilityReport, RequirementReviewRequirementPreviewRequirementReviewerRequirementsPreviewSpecReviewSystemArchitectRequirementSpec, PreliminaryReviewPreliminaryPreviewPreliminaryReviewerPreliminaryPreviewSpecReviewApplicationArchitectPreliminarySpec, DetailReviewDetailPreviewDetailReviewerDetailPreviewSpecReviewSeniorEngineerDetailSpecDeclDeveloperDecl, CodeSpecImplSpecCodePreviewerImplSpecCodeReviewCodeCommiitterToCommitEnd从这张表可以提炼出几个关键设计事实事件可以一对多广播SpecReview同时被 FeasibilityReviewer、RequirementReviewer、PreliminaryReviewer、DetailReviewer 四个智能体接收对应不同阶段文档的并行评审一个智能体可以接收多个事件Supervisor 接收Start、SpecReview、CodeReview三个事件承担总控角色一个智能体可以返回多个事件Supervisor 发送 12 种事件说明它按阶段向下游分发任务事件首尾闭合流程从Start开始到End结束。需要特别留意的是事件名的精确一致性ProductManager 返回的是RequirementPreview而 RequirementReviewer 接收的是RequirementsPreview两者在原文中拼写不同。由于事件名是智能体间协作的匹配键数据库skills.accepted_event与skills.returned_event正是按名称精确关联配置时务必核对收发双方的事件名完全一致否则技能匹配会落空。端到端流水线从 Start 到 End 的完整软件工程链路把上表沿事件方向串联起来可以看到 fcoder 定义的是一条覆盖「需求 → 设计 → 编码 → 评审 → 提交」的完整软件工程流水线共经历四个主要阶段。阶段一需求探索与可行性分析Supervisor接收Start事件后发起任务向Analyst发送RequirementsAnalyst完成需求探索后返回FeasibilityPreview可行性预览交给FeasibilityReviewer评审评审通过后返回SpecReview进入需求规格阶段。这一阶段的角色分工与 fagency.md 中「资深软件工程专家」的职责定义一一对应先按用户需求从五个不同角度阐述功能点及可行性分析对应 Analyst FeasibilityReviewer再生成《需求文档》对应 ProductManager 的RequirementPreview。阶段二需求文档、概要设计与评审ProductManager接收FeasibilityReport和RequirementReview产出RequirementPreview需求预览交给RequirementReviewer评审评审通过后返回SpecReview交给SystemArchitect系统架构师。SystemArchitect接收RequirementSpec需求规格与PreliminaryReview产出PreliminaryPreview概要预览由PreliminaryReviewer评审评审通过后返回SpecReview。随后ApplicationArchitect应用架构师接收PreliminarySpec概要规格与DetailReview产出DetailPreview详细预览由DetailReviewer评审再次返回SpecReview。注意这里的模式每个设计阶段都有一名“产出者”和一名“评审者”评审通过后统一返回SpecReview事件形成可复用的阶段完成信号。这与 软件工程.md 定义的职责链一致可行性分析 → 需求文档 → 评审需求 → 概要设计 → 评审概要设计 → 详细设计 → 评审详细设计每一步只有在用户明确指示时才进入下一步。阶段三详细设计到编码SeniorEngineer高级工程师接收DetailSpec详细规格产出Decl声明——对应软件工程专家流程中的“创建包路径”和“生成顶级声明及公共成员声明”两个步骤。Developer开发者接收Decl和CodeSpec代码与规格产出ImplSpec实现与规格——对应 实现功能点.md 定义的代码生成技能按照《详细设计文档》、包结构与语言要求返回 JSON 数组形式的实现代码。阶段四代码评审、提交与结束CodePreviewer代码评审者接收ImplSpec产出CodeReview代码评审——对应 评审代码.md仅评审是否按详细设计正确实现指定功能点并返回{review: 不符合的实现描述}格式的评审结果。评审结果经Supervisor的CodeReview事件回环若不合格则再次进入CodeSpec迭代形成“编码—评审—再编码”的循环直到通过。CodeCommiitter代码提交者接收ToCommit输出End流水线正常终结。可编辑源文件见 流程图.eddx事件、技能与智能体的数据模型支撑事件驱动的协作体系在数据库中由四张核心表支撑完整建表 SQL 见 fcoder/docs/fagency.sqlskills技能表accepted_event接收的事件名与returned_event返回的事件名定义了技能在事件图中的起止点skill_type区分primary主技能一直全部加载与auxiliary辅助技能按需加载title唯一agent_skills智能体-技能关联表以agent_id skill_id唯一索引把技能挂到智能体上一个智能体可以拥有多个技能一个技能也可以被多个智能体拥有agents智能体表agent_name唯一acceptable以逗号分隔的字符串记录“该智能体可处理的事件名”与 agentevent.md 中的“接收事件”列对应llm_type、llm_name指定该智能体使用的大模型pruner指定上下文压缩算法flows流程表category tag agent_id唯一category是流程名称tag相当于流程的版本号一个智能体可以加入不同流程。源码层面SkillsDAO.cj 中的findSkills(agentId, event)方法直接用 SQL 印证了“按照事件查询技能”的执行逻辑inner join agent_skills后按ag.agent_id ${arg(agentId)} and s.accepted_event ${arg(event)}精确匹配返回该智能体针对当前事件应加载的全部技能。loadSkills(title)则按技能标题批量加载。智能体的通用执行循环与技能响应协议结合 fagency.md 与各技能文档可以还原单个智能体的完整工作方式智能体收到事件后通过findSkills查询主技能始终加载与辅助技能按需加载把“事件 技能含 metadata 与 details”包装为大模型访问参数大模型按技能文档中定义的响应格式返回 JSON例如需要调用函数时返回{function:函数名,params:[参数1,参数2]}产出文档时返回{requirement:...}、{summary:...}、{details:...}、{feasibility:...}等评审类技能返回{review:...}缺失必要资料时返回{necessary:[资料名1,资料名2]}智能体解析 JSON 执行函数按函数返回构造新事件并继续流转。技能通过select、search、read三个内置函数访问本地知识库与搜索引擎函数调用协议定义在 functions.mdsearch是“搜索引擎 本地知识库的全文向量查询”支持embeddingWeight向量权重默认 0.7、minConfidence最低置信度默认 0.8、maxResults最大返回数默认 10等参数read按标题精确搜索本地知识库select只查询本地知识库的全文向量。这些函数把“查阅标准库、查询工具库、搜索信息”等动作收敛为可安全执行的边界避免大模型直接执行任意命令。配置要点从建表到上线运行环境与依赖fcoder 运行依赖大模型服务README 中给出示例为智谱 glm 系列glm-5 负责生成 spec、glm-5-coder 负责生成代码、glm-4.7 负责从文本提取关键词具体以当前仓库 fcoder/README.md 为准、仓颉语言环境、PostgreSQL 及其 zhparser、vector 等插件。相关建表与初始化 SQL 均集中在 fcoder/docs/fagency.sql。配置大模型建表后需向llm_conf表写入大模型配置含搜索引擎 API例如insert into llm_conf(llm_name, llm_type, llm_url, conf, token_threshold) values(glm-5, text, https://....., llm.key, 80000); -- 对于 searchllm_type 是 searchllm_name 是具体的搜索名称token_threshold是 token 阈值返回总 token 数达到该值说明上下文已满或效果明显下降。搜索用的默认引擎由 FCoderConfig.cj 中的FCODER_SEARCH_ENGINE配置项决定缺省时回退到MODEL_NAME_GLM_SEARCH_PRO。配置智能体与技能执行 fcoder/docs/fagency.sql 完成建表后再向agents、skills、agent_skills、flows等表插入数据即可把本文的事件表落地为可运行的编排agents.acceptable写入智能体可接收的事件名skills写入技能的收发事件与提示词内容agent_skills建立关联flows把智能体按category tag组织进流程。上下文管理建议fcoder 对会话上下文有明确的工程约束部署运维时值得遵循尽量保持短会话每一步都开启新的会话通过“引用之前对话的结论、利用 Git 状态、使用项目文档、#mention 相关文件”等方式在会话间传递上下文绝对不要试图在一个对话里完成所有事情丢弃部分会话历史mind skill 语言特性永远不能丢弃其余资料由技能描述决定是否加载总结会话历史纯文本会话每次总结上次返回内容全文传输更早内容传总结控制上下文占用工具历史输出用内容占位符遮盖如「内容已省略」、减少工具输出长度、参数扁平化、任务粒度尽量小并在模型宣称完成时按原始计划核对任务进度防止“过早宣告完成”。这些约束与agents.pruner字段支持的上下文压缩算法Retain、LastN_${n}、Summary_BY_${llmType}_${model}、Keywords_BY_${llmType}_${model}、DRC_...、Saturation_...等共同保障长流程任务的稳定执行。小结agentevent.md 虽然只有一张表格却是 fcoder 多智能体系统的“路由表”它把软件工程全流程映射为 13 个智能体节点和一组标准化事件边使智能体实现与业务阶段解耦——任何智能体只需“查技能、调模型、执函数、返事件”即可在不同流程中复用。理解这张表是读懂 fcoder 编排机制、配置自有智能体流水线的起点结合 fcoder/README.md、fagency.sql、SkillsDAO.cj 与 fagency.md 等资料即可在此基础上扩展出符合自己团队流程的事件链路。赞分享后端Web框架【免费下载链接】fountain一个用于服务器应用开发的综合工具库。 - 零配置文件 - 环境变量和命令行参数配置 - 约定优于配置 - 深刻利用仓颉语言特性 - 只需要开发动态链接库fboot负责加载、初始化并运行 - 覆盖服务器应用开发的各种场景项目地址https://gitcode.com/Cangjie-SIG/fountain点击查看免费下载相关推荐fountain fcoder基于仓颉语言与多智能体事件流的规范驱动 AI 编程系统fountain fcoder基于仓颉语言与多智能体事件流的规范驱动 AI 编程系统 fcoder 是 fountain 仓库中一个在命令行中运行的人工智能编后端Web框架fcoder 多智能体软件工程系统解析fountain 仓库中的事件驱动开发自动化工作流fcoder 多智能体软件工程系统解析fountain 仓库中的事件驱动开发自动化工作流 fcoder 是 fountain 开源仓库 项目根目录 http后端Web框架fountain 事件驱动流程引擎 fountain::f_egraph 完全指南事件、执行器、调度器与流程 DSL 编排fountain 事件驱动流程引擎 fountain::f_egraph 完全指南事件、执行器、调度器与流程 DSL 编排 fountain::f_egrap后端Web框架创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考