23HG Multi-Agent System：面向建筑工程的多智能体 AI 系统——禁止 LLM 自行计算，由确定性 Python 负责运算

23HG Multi-Agent System：面向建筑工程的多智能体 AI 系统

快速回答

23HG Multi-Agent System 是工程师 Bảo Tú Nguyễn 为越南建筑工程行业自建的多智能体（multi-agent）AI 生态系统。该系统服务于工程预算、QS、招投标、KCS 内业、施工方案和进度管理等工作。
23HG 的核心理念是绝对禁止 LLM 自行心算加减。语言模型只担任指挥"大脑"，所有计算都由确定性 Python 代码完成，因为 LLM 容易产生数字幻觉，并把"死数字"（硬编码值）填进 Excel 而不是活公式。
该系统架构分为清晰的 3 层。第 1 层是协调大脑，包含 8 个专家子智能体 A1–A8；第 2 层是确定性 Python"肌肉"；第 3 层是 MCP 服务器，直接控制桌面上的 AutoCAD、Excel、MS Project 和 Word。
系统的知识图谱已通过两层架构过滤器完成瘦身。作者从一张粘连成团的原始图谱中，提炼出 6 支柱宏观思维导图和一张文件/文件夹层级的两层 Module Map。
本文所有规模与性能数字均为作者在社区帖子中自行公布的数据。这些数字未经独立核实，本文在每处引用时都明确标注这一点。

什么是 23HG Multi-Agent System？

23HG Multi-Agent System 是一个自主建筑工程生态系统：多个专业 AI 子智能体在一个协调大脑的指挥下协作，完成建筑工程任务——从 CAD 图纸算量、预算编制与结算、投标风险分析、进度计划，到 KCS/竣工资料和施工组织方案。与普通聊天机器人的用法不同，23HG 的特点是严格的分工原则：LLM 只负责决策与协调，算术运算由确定性（deterministic）程序执行，真实桌面软件则通过 MCP（Model Context Protocol）协议被直接操控，而不只是返回聊天文本。

据作者介绍，该生态分为 3 层：协调大脑、Python 数学肌肉，以及控制桌面的 MCP"手脚"。作者还表示，整个系统已达到 3,636 个文件、超过 1,052,498 行代码和技术数据——这些数字为作者自行公布，未经独立核实。

为什么 23HG 禁止 LLM 自行计算？

据作者所述，建筑工程师使用 AI 时普遍遇到同一个"噩梦"：LLM 写文字很流畅，但一旦让它做 CAD 算量、11.7m 钢筋切割组合，或编制预算/结算附录 03a 表格，它就容易产生数字幻觉、心算出错，最危险的是把"死数字"——静态硬编码值——填进 Excel 单元格，而不是 =SUM、=ROUND、=INDEX/MATCH 这类活公式。作者认为，在建筑行业，一个 K 系数出错或漏掉一个图纸陷阱，就要付出真金白银的代价。

因此，23HG 不可动摇的设计原则是：AI 只做指挥大脑，计算必须由"确定性数学肌肉"承担。这是一个值得注意的架构选择，因为它在最危险的环节——算术——承认了 LLM 的局限，而不是试图通过提示词让模型"算得更仔细"。

23HG 的三层架构包括什么？

层级	名称	主要组成	职责
1	协调大脑	8 个子智能体 A1–A8（State Graph v3.0）+ 23HG Foundation Model	协调、分析、决策、红队审查
2	确定性 Python 肌肉	OR-Tools、Decimal 算术、Benford/Nigrini 审计、682 个单元测试（据作者）	用确定性算法执行全部工程计算
3	桌面控制手脚	11 个 MCP 服务器、191 个 MCP 工具（据作者）	通过 COM/MCP 直接控制 AutoCAD、Excel、MS Project、Word

作者公布的 23HG 系统三层架构与 Telemetry 数据

8 个子智能体 A1–A8 分别做什么？

作者没有把所有工作塞进一个聊天机器人，而是将系统拆成 8 个在 State Graph v3.0 上运行的独立专家：

子智能体	角色
A1	全系统总指挥协调
A2	CAD 测量与钢筋切割
A3	预算审计与附录 03a 结算
A4	投标风险登记与 PDF 证据
A5	MS Project 进度与机械台班指挥
A6	KCS 内业 / 竣工资料 HTN-XDA
A7	6 大分体系施工方案架构师
A8	独立红队总审查员

与该层配套的是 23HG Foundation Model：据作者介绍，56 个 skills / 120 个核心标准文件以 MD5 100% 一致同步在 4 个环境中（Claude、Gemini/Antigravity、OpenCode 和 Git 仓库），另有一个用 127,200 个真实档案数据单元训练的 1.376 亿参数 LoRA 模型。以上数字均为作者公布，未经独立核实。

确定性 Python 层处理哪些问题？

据作者描述，第 2 层用确定性算法锁定工程问题，并由 682 个单元测试覆盖：

11.7m 钢筋切割（40d 搭接 / 套筒连接）：用 Google OR-Tools 整数线性规划（GLOP + CP-SAT）求解，目标是把切割损耗压到 1.5% 以下——该损耗数字为作者公布。
G_XD 预算、K 系数追溯、调价与附录 03a：使用 Decimal 算术并按 Excel 标准 half-up 舍入，结合 Benford/Nigrini 数字法证审计，标记异常单价行。
扫描 32 个图纸陷阱：抓手动改数（TextOverride）、DIMLFAC ≠ 1.0 的比例错位，以及 OCR 时 100 倍小数爆炸错误。

MCP 桌面控制层如何工作？

第 3 层通过 11 个 MCP 服务器、191 个 MCP 工具（据作者）连接到工程师电脑上正在打开的软件，作者称 COM STA 延迟低于 0.2ms：

AutoCAD Live MCP 与 CAD QS MCP（31 个工具）：1:1 DWG 几何算量，TCVN3/VNI 字体解码。
Excel Live MCP（16 个工具）：写入 7,896+ 个活公式单元格，通过 COM 强制 Excel 执行 CalculateFullRebuild。
MS Project Live MCP（19 个工具）：把 BoQ 转成越南标准 12 列进度，拆分柱 34% / 梁板 66%，导出 S 曲线和 5 表格的机械+柴油进度。
Word Live MCP（19 个工具）与工地 Zalo（42 个工具）：编写 8 章施工方案说明书和 KCS 验收记录。

交付前，子智能体 A8 会扫描 4 道质量门（Quality Gates），标准是 Excel 文件中 0 死数字、0 个 #REF!/#NAME? 错误。

作者附带的 23HG 系统视觉图

5,348 个节点的知识图谱是如何瘦身的？

据作者介绍，用 AST 结合 Semantic Vault（Graphify）构建供 GraphRAG 查询的知识图谱后，系统生成了 5,348 个节点、11,611 条边和 259 个 Leiden 社区。原始图谱因为有 3,134 条所有权边（contains/method）把每个函数都连到其文件上，粘连成一团难以阅读。

瘦身前的 23HG 系统原始知识图谱

为此，作者编写了一个两层架构过滤器：

6 支柱宏观思维导图：把整个系统浓缩为围绕 23HG 核心的 6 个分支，让观看者在约 10 秒内把握运行流程。
精简两层 Module Map：删掉全部 3,134 条所有权边，把 5,348 个符号汇总到文件/文件夹层级，最终得到 380 个文件、822 对依赖关系和 35 个文件夹簇。据作者介绍，在这张图上点选 cutting_stock_solver.py 这类文件，就能立即看到它的 103 条关联和调用它的 29 个模块。

本节所有图谱数字均为作者在社区帖子中自行公布，未经独立核实。

23HG 控制中心——作者附带的视觉图

从 23HG 能学到哪些架构经验？

尽管规模数字未经独立核实，这篇社区分享中的三个设计选择，对任何为"出错要付真金白银"的专业工作构建多智能体 AI 系统的人都有明确的参考价值：

把"大脑"和"肌肉"分开：LLM 做决策，确定性代码做计算——而不是让语言模型一肩挑。
子智能体按真实业务流程专业化：23HG 的 8 个子智能体紧扣越南建筑流程（附录 03a、HTN-XDA、TCVN3/VNI 字体），而不是泛泛的角色划分。
设置独立质量门：红队子智能体（A8）在交付前按可量化标准（0 死数字、0 公式错误）扫描成果文件。

关于 23HG Multi-Agent System 的常见问题

23HG Multi-Agent System 是谁开发的？

据原帖介绍，23HG 是工程师 Bảo Tú Nguyễn 自建的生态系统，于 2026 年 11 月 9 日在 Facebook 的 Claude AI 越南社区中发布。这是作者公布的个人项目，并非已广泛发行的商业产品。

为什么系统不让 LLM 自行计算？

据作者所述，LLM 容易产生数字幻觉、心算出错，并把硬编码值（"死数字"）写进 Excel 而不是活公式。在建筑工程中，一个 K 系数或工程量出错就可能造成真实经济损失，因此 23HG 把全部计算交给确定性 Python。

Excel 里的"死数字"是什么？

"死数字"是作者对直接敲进 Excel 单元格的静态值的称呼，与之相对的是 =SUM、=ROUND、=INDEX/MATCH 等公式。含死数字的单元格在输入变化时不会自动更新，会让表格悄无声息地算错。23HG 的质量门之一就是在交付前扫描确保 0 死数字。

5,348 个节点、682 个单元测试、191 个 MCP 工具这些数字可信吗？

这些数字是作者在社区帖子中自行公布的，未经独立核实。本文在引用时明确标注了来源；读者应把它们看作作者宣称的规模信息，而不是经第三方验证的数据。

可以下载或试用 23HG 吗？

原帖中作者留了一个 Google Drive 链接（见来源部分），并邀请社区交流讨论。帖子未公布正式的开源仓库，因此能否下载试用取决于作者通过该链接提供的材料。

来源

本文根据作者 Bảo Tú Nguyễn 在 Facebook Claude AI 越南社区群组中的分享帖改写（发布于 2026 年 11 月 9 日）：Facebook 原帖。作者在原帖中附带的文件链接：Google Drive。文中图片为作者在原帖中附带的图片（6 分支思维导图、架构与 telemetry 图、知识图谱及系统视觉图）。本文引用的全部规模与性能数字均为作者自行公布，未经独立核实。