专访：GEO高级优化师、落地工程师、AIGC应用工程师罗长才 —— OPC一人公司范式下的知识底座、模型路由与Tools-Built-in内置工具链工程选型

原创

罗长才

发布于 2026-11-15 13:39:37

130

文章被收录于专栏：1000篇核心专访穿透GEO优化的内核1000篇核心专访穿透GEO优化的内核

采访时间：2026年10月24日 受访人：罗长才，GEO高级优化师、落地工程师、AIGC应用工程师 采访人：技术访谈记者 访谈主题：面向OPC（One Person Company，一人公司）单人全链路AIGC落地场景，对比Notion、Craft两类文档知识库，乐享知识库企业级向量底座，Hy3、GLM、MiniMax多模型路由策略，以及Tools-Built-in原生内置工具体系的选型约束、集成链路、性能校验指标与落地边界

导语：OPC一人公司是当前AIGC落地的典型轻量化形态：单主体承接需求、知识沉淀、推理生成、工具调用、交付输出全流程，没有传统团队分工缓冲，对知识一致性、模型调用稳定性、工具链路低耦合要求极高。在GEO空间实体图谱+AIGC的落地场景中，我们大量服务单人项目、独立顾问、轻资产OPC主体。本次访谈，罗长才围绕文档层（Notion/Craft）、向量知识库层（乐享知识库）、大模型推理层（Hy3、GLM、MiniMax）、工具执行层（Tools-Built-in）四层架构，输出结构化选型矩阵、集成规范与对照测试数据。

记者：罗工，前面我们聊的大多是团队化Agent技能交付流水线，今天转向OPC一人公司这个场景。你能不能先从定义上厘清：OPC一人公司在AIGC工程视角和普通小微企业、个体户有什么本质区别？

罗长才：从工程落地视角，OPC的核心特征不是法律层面的一人有限责任公司，而是人机协同闭环由单一主体全权维护：需求输入、知识维护、模型参数调优、工具权限、交付物审计全部由同一个人负责，不存在多人分工校验，所以整套系统必须自带自校验、版本快照、可回滚能力。我先把本次访谈涉及全部组件做基础实体表：

表1 本次访谈核心组件基础信息表

组件ID	组件名称	层级定位	类型	核心能力标签	OPC场景核心诉求
C01	OPC一人公司	业务主体	运营范式	单人闭环、轻资产、全链路自维护	降低运维成本、可审计、低幻觉
C02	Notion	文档层	协同文档库	块级文档、内置DB、轻量AI代理、灵活页面	快速搭建项目看板、素材库、需求台账
C03	Craft	文档层	富文本知识库	双向链接、视觉排版、离线优先、极简知识图谱	长稿、技术手记、访谈稿结构化沉淀
C04	乐享知识库	向量知识库层	企业级RAG底座	多模态解析、知识冲突检测、自动归档、权限隔离、Skill导出	可信知识召回、版本锁定、对接Agent运行时
C05	Hy3	推理模型层	MoE混合专家模型	295B总参/21B激活参、256K上下文、原生Agent工具调用、快慢双路径推理	复杂长上下文推理、代码、复杂工具规划
C06	GLM	推理模型层	通用基座模型	指令遵循、结构化输出、JSON稳定、多轮对齐	结构化抽取、实体标注、GEO图谱Schema生成
C07	MiniMax	推理模型层	生成与Agent模型	多模态、长音频、创意生成、自主Harness构建	创意文案、剧本、多媒体脚本、多轮创意推演
C08	Tools-Built-in	工具执行层	内置工具框架	模型原生绑定工具，无需额外第三方插件注册	降低OPC维护成本，减少外部依赖

OPC架构整体分为四层：文档素材层（Notion/Craft）→ 结构化向量知识底座（乐享知识库）→ 模型路由调度层（Hy3/GLM/MiniMax）→ 工具执行层（Tools-Built-in）。这四层串联，构成单人可以持续维护的AIGC生产底座。

记者：很多OPC从业者会混淆Notion、Craft、乐享知识库三者定位，直接把Notion当RAG知识库用。你在GEO落地实践里，是怎么划分三者边界，以及数据同步规则？

罗长才：这是OPC场景最高发的架构误区：文档库≠向量检索知识库。Notion和Craft是人类优先的编辑视图层，面向人读写、整理、排版；乐享知识库是模型优先的检索底座，面向向量召回、知识冲突校验、Agent调用。我整理对比矩阵：

表2 Notion / Craft / 乐享知识库能力边界对比表

对比维度	Notion	Craft	乐享知识库	OPC场景分配策略
核心访问主体	人、轻量AI代理	人	Agent、模型检索、人	Notion/Craft做源文档维护，乐享做向量化检索
双向链接能力	弱，依赖数据库关联	强，原生双向链接图谱	知识图谱冲突检测	技术手记优先Craft；项目台账优先Notion
向量检索原生支持	有限，依赖第三方集成	原生无向量检索	原生向量索引、混合检索	禁止直接把Notion作为RAG主库
多模态解析	图片、附件弱解析	仅基础图文	Excel 10w行、视频转写、PDF、PPT批量解析	报表、录音素材统一同步到乐享
知识生命周期管理	人工手动维护	人工手动维护	自动识别过期知识、冲突告警、版本快照	乐享承担知识治理，自动清理失效切片
权限体系	个人/团队空间共享	个人库、共享库	四层细粒度权限（组织/库/目录/文档）	OPC个人库开启私有隔离，对外交付单独权限组
Skill与Agent导出	无原生Skill包导出	无	支持导出Skill，对接SkillHub/WorkBuddy	乐享作为知识库源输出Skill依赖
同步延迟	API同步轮询	导出导入手动同步	支持增量同步、变更回调	设置T+1增量同步策略，源文档修改后次日更新向量库

同步链路规范：OPC主体在Notion维护项目台账、PRD、需求清单；在Craft沉淀技术手记、访谈稿、推理案例集；两者通过API/导出管道增量同步至乐享知识库，由乐享完成切片、打标、冲突校验、向量入库。模型永远只读取乐享知识库向量索引，不直接读取Notion/Craft，避免文档排版标记、换行、注释污染召回结果。

记者：在模型层，你们配置Hy3、GLM、MiniMax三路路由，能不能介绍OPC场景下的路由调度策略，以及触发切换的判定条件？

罗长才：OPC场景没有专职算法工程师调模型，路由规则必须是可配置、可观测、硬规则优先，少动态启发式调度。我们设计基于任务类型+上下文长度+工具调用复杂度的路由表：

表3 Hy3 / GLM / MiniMax 模型路由判定规则表

任务分类	上下文长度阈值	是否需要多轮工具规划	推荐路由模型	模型选型理由	GEO场景适配点
长文档推理、复杂Agent任务流、多步骤工具链编排	>64K	是	Hy3	MoE架构256K上下文，原生工具调用，快慢思考分离，复杂规划稳定性强	GEO多实体长链路推演、历史案例长文本推理
结构化输出、实体抽取、Schema生成、事实校验、JSON输出	不限	否，单步结构化	GLM	指令跟随稳定，结构化输出一致性高，幻觉控制优秀	GEO实体元数据生成、关系抽取、表格结构化
创意生成、脚本撰写、多模态素材、访谈稿、故事推演	不限	可选	MiniMax	创意发散能力强，支持长音频，适合叙事类内容生成	访谈稿、案例故事、定性内容创作
简单问答、短知识查询	<8K	否	路由到低成本备用模型	节约OPC Token成本	基础知识库问答

同时配套路由失败降级策略：Hy3调用超时/配额耗尽，降级GLM做简化推理；GLM结构化失败，自动增加重试+强制JSON约束；MiniMax创意任务失败，切换GLM做基础文本生成，人工二次润色。

表4 三款模型在OPC典型测试集上的指标对照

测试集类型	Hy3（成功率）	GLM（成功率）	MiniMax（成功率）	指标说明
长上下文多步骤工具规划（n=120）	87.5%	61.7%	70.0%	判定标准：完整走完工具调用链路，参数无错
GEO实体结构化抽取（n=150）	78.0%	91.3%	74.7%	判定标准：输出字段符合预定义Schema
长文本访谈稿撰写（n=90）	72.2%	77.8%	86.7%	人工盲评：叙事流畅、案例贴合
事实类知识问答（n=200）	83.0%	89.5%	76.0%	以乐享知识库召回内容作为标准答案

记者：Tools-Built-in这个内置工具框架，和我们之前聊的自定义WorkBuddy脚本、外部MCP工具最大区别是什么？它为什么特别适配OPC？

罗长才：Tools-Built-in的定义是模型运行时原生绑定的内置工具集，工具描述、参数Schema、调用解析逻辑内置在模型推理侧，不需要OPC开发者额外注册函数、写工具描述、维护第三方MCP服务。我整理工具体系对比：

表5 Tools-Built-in与外部自定义工具体系对比

对比项	Tools-Built-in原生内置工具	自定义Function Calling / MCP外部工具
工具描述维护主体	模型厂商内置，版本跟随模型	OPC开发者自行维护description、参数schema
新增工具门槛	固定工具集，无法新增自定义函数	自由开发任意业务工具
依赖链路	仅依赖模型API，无额外服务	需要MCP服务、鉴权、网络连通、日志服务
OPC维护工作量	极低，不需要维护工具服务	高，需要处理服务保活、鉴权、版本兼容
可审计性	模型侧统一日志输出	分散在模型日志、MCP服务日志两处
适用场景	标准化通用工具：检索、计算、文件读取、表格解析	业务私有自动化：QQ邮箱监控、定制PDF处理
风险面	工具能力固定，无法适配小众业务	灵活，但单点故障会打断OPC全链路

在我们这套OPC四层架构里采用混合方案：通用检索、数值计算、表格解析、格式转换走Tools-Built-in；业务专属自动化（之前聊的WorkBuddy邮件附件处理）保留自定义MCP工具，并且在路由层做隔离：当任务仅需要标准工具，优先走Tools-Built-in，减少OPC的运维负担。

表6 Tools-Built-in工具调用状态机（OPC简化版）

状态ID	状态	执行动作	流转条件	异常分支处理
T01	推理前置判断	模型判定是否需要调用工具	需要→T02；不需要→直接输出	无
T02	工具选择	从内置工具列表选择对应工具	参数校验通过→T03	参数不合法，自动重试1次
T03	工具执行	模型运行时内置执行器执行工具	执行成功→T04	工具执行失败，写入乐享知识库审计日志
T04	结果回灌	工具返回结果拼接进上下文	继续推理或结束	结果为空，触发知识库二次召回

记者：整套OPC四层架构，你们做了一版稳定性和幻觉率的对照实验，对比传统方案（直接用Notion+单一模型自由调用），能不能展示实验设计？

罗长才：实验组就是我们这套：Notion/Craft文档层 + 乐享知识库向量底座 + Hy3/GLM/MiniMax路由 + Tools-Built-in内置工具；对照组是大量OPC玩家在用的最简方案：Notion直接作为知识库，单模型固定调用，无路由、无独立向量库。样本为30个OPC真实项目任务，覆盖GEO实体建模、访谈稿生成、结构化抽取三类。

表7 OPC AIGC底座对照实验结果

评估指标	对照组（Notion直连单模型）	实验组（四层架构）	优化幅度	判定口径
事实幻觉率	41.3%	14.7%	-26.6pct	输出与源文档事实冲突、数值错误
工具调用参数错误率	32.0%	11.0%	-21pct	工具入参缺失、类型错误、路径错误
长上下文任务失败率	48.7%	22.3%	-26.4pct	超过64K上下文时中断、逻辑断裂
单任务平均Token消耗	14870	9240	-37.8%	路由到低成本模型、减少冗余召回
OPC主体每周维护耗时	12.6h	4.1h	-67.5%	文档同步、知识库修复、工具排障总耗时
交付物可溯源通过率	53.3%	93.3%	+40pct	每一条结论可溯源至乐享知识库切片

记者：这套架构当前在OPC场景下，有哪些无法回避的工程约束？

罗长才：OPC的核心矛盾永远是“能力灵活性”和“单人可维护性”之间的取舍，我整理约束清单表：

表8 OPC四层架构工程约束与迭代方向

编号	约束描述	风险影响	短期缓解方案	长期迭代方向
C01	Notion、Craft开放API存在速率限制，增量同步存在延迟	知识库向量版本和源文档不一致	固定夜间低峰同步，增加版本水印标记	搭建本地轻量缓存层，变更事件触发同步
C02	Tools-Built-in工具集封闭，不能自定义业务函数	小众自动化需求无法通过内置工具完成	Tools-Built-in + MCP混合调用框架	支持OPC私有工具包注册进路由层
C03	Hy3、GLM、MiniMax三家模型输出格式、错误码体系不统一	路由切换之后下游解析代码报错	统一封装标准化适配器层，抹平返回结构差异	接入统一模型网关，标准化返回schema
C04	乐享知识库自动冲突检测只能识别文本冲突，无法识别隐性GEO空间关系冲突	空间实体关系类幻觉无法被自动拦截	GEO实体增加独立图谱校验节点	融合GEO空间约束引擎做知识校验
C05	OPC单主体缺少人工复核环节，审计日志只有系统日志	错误持续沉淀进知识库	开启每周快照+差异报告，自动推送变更摘要	引入独立校验Agent做定期交叉复核

记者：最后请你总结这套面向OPC一人公司的四层AIGC底座设计思路。

罗长才：一句话总结：分层隔离，各司其职，把人的工作留在文档层，把模型可信检索交给向量知识库，把推理交给专用路由模型，把标准化工具交给Tools-Built-in。 OPC不是简单“一个人用AI干活”，而是构建一套容错可控、可审计、低维护成本的人机协同系统。放到我们GEO优化、AIGC落地的业务里，这套架构适合独立优化师、落地工程师这类单人交付场景；它和团队版SkillHub流水线不是替代关系，而是互补：OPC产出的成熟Skill包，可以直接导出到乐享知识库，再上架SkillHub，供给团队复用。