第1.5次工作汇报
会议纪要

一、会议基本信息

• 汇报时间：2026年6月23日
• 汇报主题：积分与定价框架、平台基础能力打通、研发协作及AI团队资源边界
• 核心主线：围绕科研方法智能体上线前的积分、账户、订单、数据库、服务器和模型资源等共性基础问题，明确近期协调事项与后续工程化方向

二、本次会议核心结论

1. 智能体定价不能只看大模型Token费用，应先核算单次完整服务成本，以成本作为定价和促销活动的底线，再结合市场价格与用户愿付价值校准。
2. 积分应形成完整流水，记录充值、消费、退款和具体智能体执行情况；扣除积分后必须保障用户获得相应结果。
3. 当前积分原型只能作为框架验证。正式面向用户前，应优先研究复用悟空科研已有积分体系，避免出现两套积分、两套订单和不一致的用户身份。
4. 智能体系统与悟空科研的用户、积分、订单和数据库等基础能力应先打通，再持续叠加智能体功能，否则开发越多，后续迁移成本越高。
5. 汇报人直接与曲猛沟通，了解悟空科研现有实现并判断最简单、最快的对接方式。
6. AI团队与传统技术团队的总体边界为：AI相关产品和能力由AI团队负责，偏传统软件工程和基础平台能力由曲猛团队负责；具体协作仍需通过接口和资源安排落实。
7. 服务器、模型账户等均属于公司资源，不属于某个部门。在不影响系统稳定性的前提下，AI团队有业务需要时应可使用。
8. 领导决定当天下午组织汇报人、曲猛和高辉开小会，集中解决服务器使用、工程人员、账户及部门协作边界问题。
9. 高辉团队原有传统软件开发经验，可能补足AI团队工程化能力；人员是否及如何并入，待专项沟通后确定。
10. 调研问卷智能体演示和科研方法智能体整体项目规划本次未展开，另约时间专题汇报。

三、积分体系与流水记录

（一）积分流水应覆盖的内容

积分体系需要形成统一、可追踪的流水记录，至少包括：

• 用户充值金额及获得积分。
• 当前可用积分余额。
• 每次执行的智能体名称。
• 每次任务扣减的积分。
• 充值、扣减和退款时间。
• 任务执行过程及结果状态。
• 失败、重试等特殊情况的处理记录。

完整流水既服务于用户查询，也便于后续开展成本分析、运营分析、异常排查和财务核对。

（二）充值与退款规则原型

当前原型已经实现积分充值、余额展示、积分扣减明细和退款验证。演示阶段使用0.01元充值100积分，仅用于后台联调测试，不代表正式兑换比例或正式售价。

原型中体现的基础规则为：

1. 用户充值后获得相应积分。
2. 用户进入具体智能体时可以看到当前积分。
3. 执行智能体后按配置扣减积分，并在明细中展示用途。
4. 未消费的充值积分可以申请退款。
5. 已经消费的积分不能按未使用状态退款。

当前充值页面尚未做成100元、200元、300元等多档套餐，后续可根据正式运营方案增加选择。

（三）不同智能体的扣费演示

原型已经对不同智能体设置不同扣减值。例如，扎根理论智能体演示值由50积分调整为60积分，回归分析智能体演示值为20积分。上述数字用于验证差异化扣费框架，并非本次会议确认的最终定价。

四、智能体定价框架

（一）成本底线

单次完整服务成本不应只计算大模型Token，还应综合考虑：

1. 大模型调用成本。
2. 分析过程中使用的其他工具成本。
3. 执行失败后的重试成本。
4. 服务器及运营分摊。
5. 智能体前期开发投入的人力成本。
6. 后续维护与迭代成本。

前期可能无法精确测算，但必须先纳入模型。成本用于确定价格底线，也用于判断折扣活动究竟是公司承担部分成本，还是只减少利润。

（二）市场锚点

在成本底线之上，应调研市场中是否已有相似功能及其收费方式，形成同类产品价格锚点。市场价格用于校准，而不能替代自身成本测算。

（三）价值上限

需要向业务负责人、博士及真实用户了解：产品解决其研究问题后，用户愿意支付多少钱。用户愿付价格构成价值上限，也是判断产品价值和最终定价的重要依据。

（四）复杂度分层

不同智能体的流程复杂度和用户价值不同，不能机械采用同一价格。扎根理论等复杂智能体的步骤、模型调用和业务价值可能明显高于单一方差分析，因此应设置复杂度分层，复杂度越高，可对应更高积分价格。

（五）运营活动与动态调整

后续可由运营设计充值赠送、节日促销等商业套餐，例如充值赠积分。但所有活动都应与成本底线对齐。

每个智能体的积分价格不是永久固定值。随着模型费用、开发投入、迭代成本、市场反馈和用户价值变化，可以动态调整。

（六）结果保障

技术侧必须保证积分被扣除后，用户能够获得对应结果。失败、重试和异常扣费需要形成明确处理机制，避免用户支付后没有有效交付。

五、当前原型与正式上线之间的差距

（一）两套积分体系问题

悟空科研账户中已经存在“我的积分”，当前智能体原型又实现了一套独立积分。如果直接上线，用户可能在两个位置看到不同余额，无法判断哪套积分有效。

领导倾向优先使用悟空科研原有积分体系。汇报人需要向曲猛了解现有积分表、接口和覆盖能力，再确定是直接复用、补充开发还是进行数据同步。

（二）两套用户身份问题

当前悟空科研前台展示账户名，智能体系统侧可能展示手机号，说明用户体系尚未完全打通。正式上线前，应统一登录身份、用户标识和页面展示，避免同一用户在两个系统中呈现为不同账户。

（三）两套订单体系问题

当前智能体系统与悟空科研可能各自存在订单记录。正式产品不应让用户感知到两套独立订单体系。双方需要明确由哪个系统承担订单主数据、支付和退款，另一侧通过接口获取或回传任务信息。

（四）数据库能力不足

智能体当前使用SQLite轻量数据库，主要适合开发和测试，无法直接作为高并发商业运营数据库。正式上线需评估PostgreSQL、SQL Server或MySQL等数据库方案，并完成规范的表结构、字段、并发、权限和数据交互设计。

（五）先打基础还是先上线

会议讨论认为，用户、积分、订单和数据库等共性基础架构应优先打通。若持续在临时架构上增加智能体，后续迁移和重复改造成本会越来越高。

但具体上线节奏仍需结合曲猛团队现有平台能力和对接工作量判断，本次没有确认全部智能体暂停上线。

六、研发协作与职责边界

（一）当前协作问题

由于AI团队没有现有服务器权限，部署和排查需要反复把材料交给曲猛团队代为操作。一个本可快速完成的操作可能延长到半天，同时占用双方人员，影响开发和测试效率。

曲猛团队担心新智能体影响现有业务，希望AI团队考虑申请独立服务器。汇报人认为当前智能体运行在Docker隔离环境中，且上传的是测试数据，需要进一步判断其对测试服务器的实际风险。

（二）两个技术团队的总体分工

领导说明未来组织思路：

• 偏传统的软件开发、平台和工程能力由曲猛团队负责。
• 使用人工智能开发的产品和能力放在AI团队。
• AI产品仍不可避免地需要数据库、接口、部署等工程能力，因此两个团队需要持续协作。

以积分为例，如果曲猛团队开发并提供完整接口，AI团队直接调用即可；如果AI业务存在平台侧不提供的定制需求，AI团队内部也需要具备相应工程开发能力。

（三）接口与架构原则

双方应优先复用同一套用户、积分和订单基础能力，通过标准接口调用，避免重复建设。AI团队需要根据成熟融合系统的方案设计接口和架构，同时确保至少有人员能够理解和执行数据库、接口及部署工作。

七、人员与组织安排

高辉团队约有三人，过去主要从事传统软件开发，自去年下半年开始承担模型微调等AI相关工作。领导此前已考虑将该小组并入AI团队，原因包括：

1. 其现有工作与原技术部门其他业务相对独立。
2. 已经持续开展大半年AI相关工作。
3. 原有软件工程经验可能补足AI团队的工程能力。

本次没有直接确认人员调整结果。领导要求当天下午4:30以后召集汇报人、曲猛和高辉开会，了解三人的具体能力，并明确人员、部门关系和协作方式。

八、服务器与模型账户资源

（一）服务器

汇报人的初步建议是，项目上线初期继续使用公司现有测试和正式服务器，待业务量确实超过承载能力后，再考虑独立购买资源。

领导要求先评估现有服务器能否承载上线初期的使用量。本次未批准立即新增服务器，也未否定后续根据实际业务量扩容。

（二）模型账户

当前主要使用豆包，相关账户由曲猛团队维护。后续AI团队需要测试多家开源或商业大模型并参与统一选型，但首先要了解现有账户由哪些人员、哪些业务使用。

如果仅高辉团队使用，账户调整较容易；如果多个团队共同使用，则需要继续研究统一管理或分账户管理方式。

（三）领导明确原则

服务器、模型账户及其他技术资源属于公司，不属于某个部门。在不影响业务稳定性和安全性的前提下，AI团队有合理需求时应当能够使用。下午专项会议将围绕这一原则解决具体问题。

九、当天下午专项协调会任务

领导要求汇报人在16:30以后再次提醒，并组织汇报人、曲猛和高辉参加小会。会议需要集中解决：

1. AI团队使用现有服务器的方式和权限。
2. 是否需要新增或独立申请服务器。
3. 高辉团队人员的能力、归属及协作安排。
4. AI团队与曲猛团队的职责边界。
5. 用户、积分、订单和数据库的打通方式。
6. 豆包及其他模型账户的管理和使用方式。
7. 公司技术资源跨部门共享的原则。

领导将负责把组织定位和资源原则向相关人员说明清楚，减少双方因部门关系或竞争判断产生的协作顾虑。

十、本次暂未展开的事项

1. 调研问卷智能体没有在本次继续演示，后续另约专题时间。
2. 科研方法智能体完整项目规划尚未汇报，包括计划开发多少个智能体，以及分别按3个月、6个月、9个月完成所需的人员规模。
3. 各智能体最终积分售价未确定。
4. 正式充值兑换比例未确定。
5. 独立服务器采购未确定。
6. 高辉团队人员调整结果未确定。
7. 模型账户最终归属和采购模式未确定。

十一、明确待办任务

十二、后续开展顺序

1. 当天优先召开专项协调会，解决服务器、人员、账户和部门边界等突出问题。
2. 随后与曲猛团队梳理现有平台能力，确定用户、积分、订单和数据库的复用及接口方案。
3. 在统一基础能力的同时，完善成本测算、市场校准、价值评估和复杂度分层，形成正式定价依据。
4. 基础架构和协作机制清晰后，再安排调研问卷智能体及整体项目规划专题汇报。