参赛项目名称
ScholarForge OS｜研语工坊
面向科研人员的多 Agent 学术英语审校与投稿工作台。
团队 / 作者
我做了什么
我开发了一套面向硕士生、博士生和科研人员的多 Agent 科研英语审校系统。
传统科研英语工具通常只负责语法润色，用户很难判断修改是否改变了科学含义，也无法区分语言问题、术语问题、逻辑问题和方法完整性问题。
ScholarForge OS 将科研英语审校拆分为 4 个独立的专业 Agent：
-
Terminology Guardian
- 检查专业术语、缩写、单位、符号和材料名称的一致性
- 建立推荐术语与避免混用表达
-
Academic Editor
- 检查语法、搭配、时态、语态和学术表达
- 在不增加新实验事实的前提下生成保守修改稿
-
Logic Auditor
- 检查因果关系过度、结论扩大、逻辑跳跃和证据不足
- 将过强结论改为更符合科研证据边界的表达
-
Method Auditor
- 检查样本数量、试件尺寸、设备参数、测试条件、重复次数和统计方法
- 缺失信息不会被 AI 擅自补写，而是使用
[Please provide ...] 标记为作者待办事项
4 个 Agent 分别调用阿里云百炼模型，并通过并行工作流执行。所有结果由本地确定性聚合器统一完成：
- 问题规范化与去重
- 术语规则合并
- 科学含义保护
- 新增数值检测
- 投稿准备度评分
- Reviewer Decision 判定
- 审校报告与结构化结果生成
系统坚持“模型负责专业判断，代码负责最终规则”，避免出现评分与审稿结论矛盾的问题。
当前已经实现：
- 科研英文在线审校
- 4 个独立百炼 Agent 并行运行
- 原文与修改稿对照
- 问题位置、严重程度和修改原因
- 专业术语规则生成
- Agent 运行状态、模型、耗时和问题数量展示
- 确定性投稿准备度评分
- Major Revision、Minor Revision、Ready for Submission 判定
- 科学含义与新增数值保护
- TXT 修改稿下载
- Markdown 审校报告下载
- JSON 结构化结果下载
- Vercel 公网部署
- GitHub Actions 自动类型检查与生产构建
使用的工具
- OpenWork / 百炼 CLI： 当前线上版本未直接依赖 OpenWork，主要通过阿里云百炼 API 集成模型能力
- 百炼能力 / 模型： 阿里云百炼 OpenAI 兼容 API、
qwen-plus
- Skill 名称： 自定义 Multi-Agent Academic Manuscript Review 工作流，未直接使用预设 Skill
- 其他：
- Next.js 16
- React 19
- TypeScript
- Vercel
- GitHub
- GitHub Actions
- Browser Blob 文件导出
效果展示
1. 多 Agent 科研英语审校工作台
系统采用三栏工作台设计：
- 左侧：论文项目、Agent 团队状态和科学保护规则
- 中间：论文输入、原文与修改稿对照、问题中心、术语库和运行轨迹
- 右侧：投稿准备度、Reviewer Decision、审校指标和交付物
2. 真实多 Agent 并行执行
每次启动全面审校，系统会分别调用：
- Terminology Guardian
- Academic Editor
- Logic Auditor
- Method Auditor
每个 Agent 都拥有独立的提示词、模型响应、运行耗时、问题数量和失败状态。
3. 可追踪的问题证据
每条审校问题都会展示：
- 来源 Agent
- 问题位置
- 原始表达
- 建议修改
- 严重程度
- 修改原因
- 是否可能改变科学含义
4. 投稿准备度与交付物
系统根据发现的问题，由代码统一计算投稿准备度和 Reviewer Decision，并支持下载：
Revised_Manuscript.txtAudit_Report.mdReview_Result.json
项目链接
踩坑记录
1. 页面显示多个 Agent，不代表后台真的运行了多个 Agent
最初版本只进行了一次模型调用，再通过提示词模拟术语、语言、逻辑和方法四种角色。
虽然前端看起来像多 Agent，但后台并没有真实的独立任务。
后续我将其重构为 4 个独立百炼请求，并通过 Promise.all 并行执行。每个 Agent 现在都有独立提示词、独立响应、独立耗时和独立错误状态。
2. 不能让模型直接决定最终评分
早期版本曾出现“修改后评分较高，但 Reviewer Decision 仍然是 Major Revision”的逻辑冲突。
现在模型只负责发现专业问题，最终评分和 Reviewer Decision 由代码根据问题类别、严重程度和未解决风险统一计算，从而保证评分、问题数量和审稿结论一致。
3. 科研英语不能只追求语言流畅
模型有时会为了让论文内容看起来更完整，加入原文没有提供的试验解释、设备参数或数值信息。
因此系统增加了科研安全规则：
- 不虚构实验、样本数量、设备参数、标准和参考文献
- 不允许修改稿增加原文没有的新数值
- 缺失信息只能使用
[Please provide ...] 作者占位符
- 逻辑和方法学重大问题不会因为语言变流畅而自动消失
4. 多 Agent 串行调用容易超时
如果 4 个 Agent 按顺序运行，整体耗时容易超过 Serverless Function 的执行限制。
因此当前工作流采用并行调用，并为每个 Agent 设置独立超时和局部失败隔离。即使其中一个 Agent 调用失败，其他成功结果仍然可以正常展示。
5. 不能展示尚未实现的虚假交付物
早期页面展示了 DOCX、XLSX 和 PDF 文件卡片，但当时并不能真正下载。
后续删除了这些虚假入口，改为提供已经真实实现的 TXT、Markdown 和 JSON 下载。DOCX 修订模式和正式 PDF 报告被明确列入后续版本路线图。
参赛项目名称
ScholarForge OS｜研语工坊
面向科研人员的多 Agent 学术英语审校与投稿工作台。
团队 / 作者
我做了什么
我开发了一套面向硕士生、博士生和科研人员的多 Agent 科研英语审校系统。
传统科研英语工具通常只负责语法润色，用户很难判断修改是否改变了科学含义，也无法区分语言问题、术语问题、逻辑问题和方法完整性问题。
ScholarForge OS 将科研英语审校拆分为 4 个独立的专业 Agent：
Terminology Guardian
Academic Editor
Logic Auditor
Method Auditor
[Please provide ...]标记为作者待办事项4 个 Agent 分别调用阿里云百炼模型，并通过并行工作流执行。所有结果由本地确定性聚合器统一完成：
系统坚持“模型负责专业判断，代码负责最终规则”，避免出现评分与审稿结论矛盾的问题。
当前已经实现：
使用的工具
qwen-plus效果展示
1. 多 Agent 科研英语审校工作台
系统采用三栏工作台设计：
2. 真实多 Agent 并行执行
每次启动全面审校，系统会分别调用：
每个 Agent 都拥有独立的提示词、模型响应、运行耗时、问题数量和失败状态。
3. 可追踪的问题证据
每条审校问题都会展示：
4. 投稿准备度与交付物
系统根据发现的问题，由代码统一计算投稿准备度和 Reviewer Decision，并支持下载：
Revised_Manuscript.txtAudit_Report.mdReview_Result.json项目链接
踩坑记录
1. 页面显示多个 Agent，不代表后台真的运行了多个 Agent
最初版本只进行了一次模型调用，再通过提示词模拟术语、语言、逻辑和方法四种角色。
虽然前端看起来像多 Agent，但后台并没有真实的独立任务。
后续我将其重构为 4 个独立百炼请求，并通过
Promise.all并行执行。每个 Agent 现在都有独立提示词、独立响应、独立耗时和独立错误状态。2. 不能让模型直接决定最终评分
早期版本曾出现“修改后评分较高，但 Reviewer Decision 仍然是 Major Revision”的逻辑冲突。
现在模型只负责发现专业问题，最终评分和 Reviewer Decision 由代码根据问题类别、严重程度和未解决风险统一计算，从而保证评分、问题数量和审稿结论一致。
3. 科研英语不能只追求语言流畅
模型有时会为了让论文内容看起来更完整，加入原文没有提供的试验解释、设备参数或数值信息。
因此系统增加了科研安全规则：
[Please provide ...]作者占位符4. 多 Agent 串行调用容易超时
如果 4 个 Agent 按顺序运行，整体耗时容易超过 Serverless Function 的执行限制。
因此当前工作流采用并行调用，并为每个 Agent 设置独立超时和局部失败隔离。即使其中一个 Agent 调用失败，其他成功结果仍然可以正常展示。
5. 不能展示尚未实现的虚假交付物
早期页面展示了 DOCX、XLSX 和 PDF 文件卡片，但当时并不能真正下载。
后续删除了这些虚假入口，改为提供已经真实实现的 TXT、Markdown 和 JSON 下载。DOCX 修订模式和正式 PDF 报告被明确列入后续版本路线图。