# Textira 技术实践：从 Research State 到 LaTeX 的科研 AI 工作流

在做 Textira 的过程中，我们最开始讨论得最多的并不是“怎么让 AI 写出一篇论文”，而是一个更基础的系统设计问题：**科研项目的基本单位到底应该是什么？**

如果把它设计成 Conversation，系统会很像 ChatGPT：研究过程被组织成一轮轮对话；如果把它设计成 Document，又会更接近传统论文编辑器，所有能力最终围绕一份 Word 或 LaTeX 文档展开。

但真实的科研过程并不是从一个空白文档开始的。

一项研究往往先有文献和研究问题，然后出现实验设计、代码、数据、指标和图表，最后其中一部分内容才逐渐进入论文。与此同时，研究者可能还在 Google Scholar 找文献，在 Zotero 管理引用，在 JupyterLab 跑实验，最后进入 Overleaf 处理 LaTeX。

```text
Literature
    ↓
Research Question
    ↓
Experiment
    ↓
Data / Metrics
    ↓
Figures
    ↓
Manuscript
    ↓
LaTeX / PDF
```

真正麻烦的地方也出现在这里：**每一个工具都完成了自己的任务，但一项研究的上下文被拆散了。**

例如实验已经运行了十几轮，Jupyter 里保存着数据和图，Zotero 里有准备引用的论文，AI Conversation 中又讨论过几轮结果。等真正开始写 Results 时，研究者仍然需要重新确认：论文里的某个数字来自哪次实验？某张图对应哪一版数据？一句 Related Work 背后的引用到底是哪篇论文？

因此在 Textira 的设计里，我们最后没有把 Conversation 或 Document 作为整个系统的顶层对象，而是引入了另一个对象：

```text
Research
```

论文只是 Research 最终产生的 Artifact 之一。

这也成为后面知识库、文献、实验、科研绘图、Agent 和 Visual + LaTeX 编辑器如何组织的起点。

## 1. 从 Document State 转向 Research State

一个普通 AI 对话系统最自然的数据结构通常是 Conversation：

```json
{
  "conversation_id": "conv_001",
  "messages": [
    {
      "role": "user",
      "content": "帮我分析这组实验结果"
    },
    {
      "role": "assistant",
      "content": "从结果来看……"
    }
  ]
}
```

这种结构很适合问答，但科研持续几周甚至几个月以后会出现问题。

假设今天上传：

```text
experiment_v3.csv
```

明天又产生：

```text
experiment_final.csv
```

几天以后论文里出现：

```text
Accuracy improved by 3.7%.
```

如果研究状态主要存在 Conversation 里，系统很难稳定回答一个非常重要的问题：

> **这个 3.7% 来自哪一次实验？**

Document 同样只能解决一部分问题。

一个典型 LaTeX Project 更接近：

```text
paper/
├── main.tex
├── references.bib
├── figures/
│   ├── figure_1.pdf
│   └── figure_2.pdf
└── sections/
    ├── introduction.tex
    ├── method.tex
    └── results.tex
```

它非常适合维护最终论文，却没有必要知道 `figure_2.pdf` 前面经历过多少轮实验。

因此 Textira 在这一层做的第一个区分是：

| 对象 | 保存的主要状态 | 适合解决的问题 |
| --- | --- | --- |
| Conversation | Messages | 当前讨论 |
| Document | Content | 正文编辑与排版 |
| Research | Evidence + State + Artifacts | 一项研究从资料到论文的过程 |

在这个模型里，Manuscript 不再是系统本身，而是 Research 中的一部分：

```text
Research
│
├── Knowledge
├── Literature
├── Experiments
├── Data
├── Figures
└── Manuscript
```

对应到一个简化的数据结构，可以写成：

```typescript
interface Research {
  id: string;
  title: string;

  knowledge: KnowledgeItem[];
  literature: Paper[];
  experiments: Experiment[];
  datasets: Dataset[];
  figures: FigureArtifact[];

  manuscript: Manuscript;
}
```

这里的代码只是为了说明数据关系，并不是 Textira 生产环境中的完整实现。

真正重要的是对象边界发生了变化：

> **不是先创建一篇论文，再往里面塞研究材料；而是先存在一项 Research，论文逐渐从 Research State 中形成。**

这也是后续科研 AI 工作流能够继续往下设计的基础。

## 2. Research State 不等于全部塞进 Context

Research 成为顶层对象以后，很快会遇到第二个工程问题：如果一项研究里已经有几十篇论文、多轮实验、数据文件、图片和几万字正文，难道每次调用模型都把它们全部放进 Context？

显然不合适。

因此在 Textira 这类 Research-oriented workflow 中，长期状态和模型当前上下文需要分开考虑：

```text
Research State
      │
      ↓
Task Resolver
      │
      ↓
Context Builder
      │
      ├── Relevant Literature
      ├── Experiment Results
      ├── Figures
      └── Manuscript Section
      │
      ↓
     LLM
```

假设当前任务是：

> 根据 Experiment 17 修改 Results，并解释为什么 F1 下降。

这次调用真正需要的可能只有 Experiment 17、对应图表、少量相关文献和 `results.tex`，而不是整项 Research。

一个高度简化的 Context Builder 可以表示为：

```typescript
async function buildResearchContext(
  researchId: string,
  task: ResearchTask
) {
  const context = [];

  if (task.experimentIds?.length) {
    context.push(
      await loadExperiments(researchId, task.experimentIds)
    );
  }

  if (task.paperIds?.length) {
    context.push(
      await loadLiterature(researchId, task.paperIds)
    );
  }

  if (task.figureIds?.length) {
    context.push(
      await loadFigures(researchId, task.figureIds)
    );
  }

  if (task.section) {
    context.push(
      await loadManuscriptSection(researchId, task.section)
    );
  }

  return context;
}
```

这里可以把 Textira 的这一层设计概括成一句话：

**Research 保存长期状态，Context 只组装当前任务真正需要看到的状态。**

这比单纯扩大模型 Context Window 更重要，因为科研项目里的问题通常不是“模型一次能读多少”，而是“模型这一次究竟应该读什么”。

## 3. 文献进入 AI 后，不能丢掉 Citation Identity

科研知识库很容易被简化成一个 RAG 流程：

```text
PDF
 ↓
Parse
 ↓
Chunk
 ↓
Embedding
 ↓
Vector DB
 ↓
Retrieve
 ↓
LLM
```

用来问“这篇论文讲了什么”，这个流程通常已经能够工作。

但进入 Manuscript 阶段以后，只返回相似文本还不够。

因为模型可能写出：

```text
Previous studies have shown that...
```

接下来必须能够回答：

**Previous studies 到底是哪篇论文？**

因此在 Textira 的 Research State 中，文献 Chunk 更重要的是不能脱离 Paper Identity。一个简化对象可能包含：

```json
{
  "chunk_id": "chunk_193",
  "paper_id": "paper_42",
  "title": "Example Paper",
  "doi": "10.xxxx/example",
  "page": 7,
  "section": "Results",
  "text": "..."
}
```

整个链路因此不是简单的：

```text
Retrieve → Text
```

而更接近：

```text
Query
  ↓
Retriever
  ↓
Evidence Chunk
  ↓
Paper Identity
  ↓
Citation Candidate
  ↓
Manuscript
```

这也是科研 RAG 和普通知识库问答之间一个很容易被忽略的差异：**检索到内容只是第一步，写进论文以后还需要知道内容来自哪里。**

## 4. Experiment 到 Manuscript，需要保留数据来源

实验数据也是同样的问题。

假设论文 Results 中出现：

```text
F1 = 0.873
```

理想状态下，它不应该只是 Manuscript 中的字符串。

它背后应该存在一条可以解释的数据关系：

```text
Manuscript Claim
      ↓
Metric
      ↓
Experiment Run
      ↓
Dataset / Config
```

例如：

```typescript
interface Metric {
  name: string;
  value: number;
  experimentId: string;
  runId: string;
  sourceFile?: string;
}
```

正文中的 Claim 则可以关联 Evidence：

```json
{
  "claim": "The proposed method achieved an F1 score of 0.873.",
  "evidence": {
    "type": "metric",
    "experiment_id": "exp_017",
    "run_id": "run_004",
    "metric": "f1",
    "value": 0.873
  }
}
```

Textira 在这里想解决的并不是“让 AI 更会编 Results”，而恰恰是反过来：

> **AI 可以负责理解和表达实验结果，但数字应该尽可能来自 Research State 中已经存在的实验事实。**

当 Manuscript 与 Experiment 不再完全断开以后，AI 能做的事情反而更加明确。

## 5. Figure 也应该是 Research Artifact

科研绘图同样不应该只是“生成一张图片”。

例如：

```python
import pandas as pd
import matplotlib.pyplot as plt

df = pd.read_csv("experiment_17.csv")

summary = (
    df.groupby("method")["f1"]
      .mean()
      .sort_values(ascending=False)
)

summary.plot(kind="bar")
plt.ylabel("F1 Score")
plt.tight_layout()
plt.savefig("figure_4.pdf")
```

真正值得保存的是这条关系：

```text
experiment_17.csv
        ↓
     analysis
        ↓
   figure_4.pdf
        ↓
 Figure 4 in Manuscript
```

如果后续实验变成：

```text
experiment_17_v2.csv
```

那么系统至少有机会判断：

```text
Experiment changed
        ↓
Figure source changed?
        ↓
Figure stale?
        ↓
Regenerate / Review
```

在 Textira 的 Research 模型里，把 Figure 看作 Research Artifact，而不只是 Manuscript 中的一张图片，正是为了保留这层关系。

这比“AI 能不能画一张论文风格的图”更值得解决。

## 6. Visual + LaTeX 不一定是两个编辑器

Research State 最后还是需要进入论文。

但如果直接：

```text
Research → LLM → main.tex
```

又会产生新的问题：研究事实、正文表达和 LaTeX 表现层重新混在一起。

一种更容易维护的方式是：

```text
Research State
      ↓
Evidence Context
      ↓
Manuscript Model
      ↓
Structured Document
      │
      ├── Visual Editor
      │
      └── LaTeX Renderer
              ↓
             PDF
```

例如 Manuscript 内部先维护：

```json
{
  "section": "results",
  "blocks": [
    {
      "type": "paragraph",
      "content": "..."
    },
    {
      "type": "figure",
      "figure_id": "fig_004"
    },
    {
      "type": "citation",
      "paper_id": "paper_042"
    }
  ]
}
```

然后再渲染成：

```latex
\section{Results}

Our method achieved an F1 score of 0.873...

\begin{figure}[t]
  \centering
  \includegraphics[width=\linewidth]{figure_4.pdf}
  \caption{Comparison of F1 scores across methods.}
  \label{fig:results}
\end{figure}
```

Textira 目前采用 Visual + LaTeX 的方向，本质上也是在处理这个问题：研究者可以在更直观的编辑界面里处理内容，同时最终论文仍然能够进入 LaTeX 的模板、公式、引用和编译体系。

从系统设计角度看，它们不一定是两套互相竞争的编辑器，而可以理解成同一份 Manuscript State 的不同表现层。

## 7. Agent 应该操作 Research State，而不是只返回一段文字

当 Agent 加入以后，这套结构才真正开始变得有意思。

最简单的 AI 写作链路是：

```text
Prompt
  ↓
LLM
  ↓
Text
```

但 Research Agent 更合理的工作方式应该是调用工具：

```text
                    Research Agent
                           │
        ┌──────────────────┼──────────────────┐
        ↓                  ↓                  ↓
 Literature Tool    Experiment Tool    Manuscript Tool
        │                  │                  │
        ↓                  ↓                  ↓
     Papers             Metrics            Sections
        │                  │                  │
        └──────────────────┼──────────────────┘
                           ↓
                    Research State
                           │
                           ↓
                         Human
```

例如工具层可以抽象为：

```typescript
const tools = {
  searchLiterature,
  getExperimentResult,
  analyzeDataset,
  generateFigure,
  updateManuscript,
  compileLatex
};
```

当研究者说：

```text
根据最新实验更新 Results。
如果 Figure 4 已经过期就重新生成，
不要修改 Introduction。
```

理想的 Agent Execution 更接近：

```text
1. getExperimentResult()
2. compareFigureSource()
3. generateFigure()       // only if stale
4. updateManuscript()
5. compileLatex()
6. return diff
```

而不是直接返回：

```text
“好的，以下是修改后的 Results……”
```

所以在 Textira 的设计里，我们更希望 Agent 是 **Research State 的受控操作者**，而不仅是一个能输出更长文本的模型。

## 8. 为什么最后仍然需要 Human Gate

科研工作流还有一个不能被 Agent 吞掉的节点：

```text
Research State
      ↓
Agent
      ↓
Proposed Change
      ↓
Human Review
      ↓
Commit
```

尤其是涉及实验结论、关键数字、引用变化、方法描述和最终结论时，模型提出修改与修改真正进入 Manuscript，应该是两件事情。

例如：

```typescript
interface ManuscriptPatch {
  section: string;

  before: string;
  after: string;

  evidence: EvidenceRef[];
  requiresReview: boolean;
}
```

Agent 负责产生 Patch，并说明使用了哪些 Evidence；研究者决定是否接受。

这种设计会牺牲一点“AI 一键生成论文”的爽感，却更符合科研工作本身。

因为科研系统最终需要优化的并不是：

```text
生成了多少字
```

而是：

```text
这句话为什么出现在论文里？
这个数字来自哪里？
这张图对应哪份数据？
这条引用支持什么结论？
```

## 9. 把整个 Textira Research Workflow 串起来

到这里，Textira 的整体思路就比较容易画出来了：

```text
                     Research
                        │
        ┌───────────────┼───────────────┐
        ↓               ↓               ↓
    Knowledge       Literature      Experiment
        │               │               │
        │               │          Data / Metrics
        │               │               │
        └───────────────┼───────────────┘
                        ↓
                  Research State
                        │
                        ↓
                 Context Builder
                        │
                        ↓
                  Research Agent
                        │
          ┌─────────────┼─────────────┐
          ↓             ↓             ↓
       Evidence       Figure      Manuscript
                                      │
                                      ↓
                             Structured Document
                                ↙           ↘
                         Visual Editor    LaTeX
                                ↘           ↙
                                    PDF
```

如果把常见科研工具也放进这个模型，会更容易理解它们之间的区别：

| 工具 | 核心对象 | 更擅长处理 |
| --- | --- | --- |
| ChatGPT / Claude | Conversation | 讨论、阅读、代码和临时任务 |
| Zotero | References | 文献与引用 |
| JupyterLab | Notebook | 实验、数据与分析 |
| Overleaf | LaTeX Document | 论文编辑、编译与排版 |
| Textira | Research | 连接文献、实验、数据、图表与 Manuscript |

这并不意味着 Research Workspace 要替代所有科研工具。

更现实的目标是：**研究者继续使用适合自己的工具，但当内容进入论文时，不需要每次重新向 AI 解释整项研究。**

## 写在最后

做 Textira 以后，我越来越觉得，“AI 写论文”可能不是描述科研 AI 最准确的方式。

真正的科研过程仍然是：

```text
Literature
    ↓
Research Question
    ↓
Experiment
    ↓
Data
    ↓
Evidence
    ↓
Manuscript
    ↓
Publication
```

AI 可以参与检索，可以分析数据，可以生成图表，可以帮助表达，也可以通过 Agent 修改 Manuscript。

但它不应该把中间这条研究链路直接压缩成：

```text
Prompt → Paper
```

从工程角度看，科研 AI 更值得解决的问题也许不是“怎样一次生成更多文字”，而是另一件更基础的事情：

**当 AI 真正进入研究流程以后，文献、实验、数据、图表和论文之间的关系，怎样才能仍然保持连接。**

这也是 Textira 把基本单位从 Conversation 和 Document 往前推进到 Research 的原因。

在做 Textira 的过程中，我们最开始讨论得最多的并不是“怎么让 AI 写出一篇论文”，而是一个更基础的系统设计问题：科研项目的基本单位到底应该是什么？

Textira 技术实践：从 Research State 到 LaTeX 的科研 AI 工作流

科研 AI 真正难处理的，不只是生成文字，而是当文献、实验、数据、图表和论文分散在不同工具中时，如何保持研究上下文的连续性。本文结合 Textira 的技术实践，从 Research State 出发，拆解 Context Builder、文献证据与引用身份、实验数据溯源、Structured Document、Visual + LaTeX，以及 Research Agent 的工作流设计

人工智能

架构设计

开发工具

Textira通过ResearchState架构重构科研AI工作流，以Research为顶层对象连接文献、实验、数据与图表，保留证据来源和引用身份。通过ContextBuilder精准组装任务上下文，Agent受控操作长期状态，Manuscript作为衍生产物，实现从研究过程到LaTeX论文的可追溯、可验证的科研闭环。

数据结构

代码解释

ChatGPT

Agent

2026上云采购 | AI焕新·智启新局

lexiang

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Textira 技术实践：从 Research State 到 LaTeX 的科研 AI 工作流-腾讯云开发者社区-腾讯云

Textira 技术实践：从 Research State 到 LaTeX 的科研 AI 工作流

Textira 技术实践：从 Research State 到 LaTeX 的科研 AI 工作流

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐