企业官网建设流程全解析

• 后端
• Web框架

fcoder 是 fountain 项目中一款命令行下的人工智能编程工具，它用「智能体（Agent）+ 事件（Event）」的模型把软件工程全流程拆解为一条可编排的流水线。agent&event.md 是这套机制的核心定义文件，它用一张对照表明确了 13 个智能体各自的职责边界、接收事件与返回事件。阅读本文后，你将掌握 fcoder 的事件流转规则、智能体编排方式，以及如何结合数据库结构与源码理解并扩展这套多智能体协作体系。

事件驱动模型：智能体是节点，事件是数据，技能是边

在 fcoder 中，一次软件开发任务不是由单个大模型从头到尾完成的，而是被拆解为一系列事件（Event），由不同的**智能体（Agent）**接力处理。理解这三层关系是掌握整个体系的前提，相关说明详见 fcoder/README.md：

• 智能体是流程的节点。执行一次流程时，一个智能体可能多次接收不同的事件，并使用不同的技能处理；
• 事件是沿着技能边在各个智能体节点之间流转的数据。事件名是智能体之间通信的“协议”，一个智能体只处理它能接收的事件；
• 技能（Skill）是流程的边，是原子化的，只做一件事。一个技能只能处理一个确定的事件，并返回一个由所执行函数确定的事件（或由大模型直接返回的事件）。

正是因为有了这张事件表，智能体的实现可以做到高度通用：智能体的代码不需要关心当前正在处理什么事件，也不需要关心该由哪个技能处理，它只需要按固定循环执行：

1. 按照事件查询技能；
2. 把事件和技能包装为大模型访问参数；
3. 按照大模型返回的 JSON 去执行函数；
4. 按照函数返回结果构造事件、返回事件。

这样做的好处很直接：省去了让大模型判断“该用哪个技能、调用哪个函数”所消耗的 tokens，也不必为每个智能体编写技能列表和选择逻辑的提示词；同时由于智能体通过函数执行功能而不是直接执行命令，可以在函数层做参数检查、误删保护等边界处理，提升安全性。

智能体与事件完整对照表

agent&event.md 以一张表格完整定义了各智能体的职责。下表为原文的完整内容（表中事件名为系统内定义的专有名词，保留原文；其中CodeCommiitter、CodeCommitation为原文定义写法，配置时需保持一致）：

从这张表可以提炼出几个关键设计事实：

• 事件可以一对多广播：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发送Requirements；Analyst完成需求探索后返回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和Code&Spec（代码与规格），产出Impl&Spec（实现与规格）——对应 实现功能点.md 定义的代码生成技能：按照《详细设计文档》、包结构与语言要求返回 JSON 数组形式的实现代码。

阶段四：代码评审、提交与结束

CodePreviewer（代码评审者）接收Impl&Spec，产出CodeReview（代码评审）——对应 评审代码.md：仅评审是否按详细设计正确实现指定功能点，并返回{"review": "不符合的实现描述"}格式的评审结果。评审结果经Supervisor的CodeReview事件回环，若不合格则再次进入Code&Spec迭代，形成“编码—评审—再编码”的循环，直到通过。

CodeCommiitter（代码提交者）接收ToCommit，输出End，流水线正常终结。

（可编辑源文件见 流程图.eddx）

事件、技能与智能体的数据模型支撑

事件驱动的协作体系在数据库中由四张核心表支撑，完整建表 SQL 见 fcoder/docs/fagency.sql：

• skills（技能表）：accepted_event（接收的事件名）与returned_event（返回的事件名）定义了技能在事件图中的起止点；skill_type区分primary（主技能，一直全部加载）与auxiliary（辅助技能，按需加载）；title唯一；
• agent_skills（智能体-技能关联表）：以agent_id + skill_id唯一索引把技能挂到智能体上，一个智能体可以拥有多个技能，一个技能也可以被多个智能体拥有；
• agents（智能体表）：agent_name唯一，acceptable以逗号分隔的字符串记录“该智能体可处理的事件名”，与 agent&event.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 与各技能文档，可以还原单个智能体的完整工作方式：

1. 智能体收到事件后，通过findSkills查询主技能（始终加载）与辅助技能（按需加载）；
2. 把“事件 + 技能（含 metadata 与 details）”包装为大模型访问参数；
3. 大模型按技能文档中定义的响应格式返回 JSON，例如：
   • 需要调用函数时返回{"function":"函数名","params":["参数1","参数2"]}；
   • 产出文档时返回{"requirement":"..."}、{"summary":"..."}、{"details":"..."}、{"feasibility":"..."}等；
   • 评审类技能返回{"review":"..."}；
   • 缺失必要资料时返回{"necessary":["资料名1","资料名2"]}；
4. 智能体解析 JSON 执行函数，按函数返回构造新事件并继续流转。

技能通过select、search、read三个内置函数访问本地知识库与搜索引擎，函数调用协议定义在 functions.md：search是“搜索引擎 + 本地知识库的全文+向量查询”，支持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); -- 对于 search，llm_type 是 'search'，llm_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_...等）共同保障长流程任务的稳定执行。

小结

agent&event.md 虽然只有一张表格，却是 fcoder 多智能体系统的“路由表”：它把软件工程全流程映射为 13 个智能体节点和一组标准化事件边，使智能体实现与业务阶段解耦——任何智能体只需“查技能、调模型、执函数、返事件”，即可在不同流程中复用。理解这张表，是读懂 fcoder 编排机制、配置自有智能体流水线的起点；结合 fcoder/README.md、fagency.sql、SkillsDAO.cj 与 fagency.md 等资料，即可在此基础上扩展出符合自己团队流程的事件链路。

• 后端
• Web框架