科研Agent能力边界与本地部署实测：从文献结构化到批量实验

“AI 做科研的能力已经远超博士生”这个说法在技术圈传了不短时间，但真正把这句话拆开看，会发现它描述的其实是某几类具体任务上的局部优势，而不是整体科研能力的超越。围绕这个话题，做 Agent 的工程团队和一线科研人员的判断分歧往往集中在同一个地方：Agent 在“给定清晰目标的执行类任务”上确实快得离谱，但在“定义问题、判断什么值得做、承担结论责任”这几件事上，还差得很远。这篇文章不打算停留在观点层面互喷，而是把这场讨论翻译成一套能落地验证的工程方案：科研 Agent 到底覆盖了哪些环节、本地怎么部署、用什么任务去测它、测出来的结果怎么读、显存和 token 成本怎么估、踩坑了怎么排查。

先把结论放前面：如果你所在的方向是计算密集型、数据密集型的科研工作，比如复现一篇论文的实验、跑一批超参搜索、从几百篇文献里抽结构化信息、把散乱的实验日志整理成结论，那么现在的 Agent 工具链已经能实打实替你省下大量时间。但如果你指望它替你选题、判断一个新方向值不值得投入三年、或者在组会上为一个结论背书，那它现在还做不到，而且短期内也做不到。这两件事的差距不是模型能力差一点，而是任务性质不同。

本文会带你完成四件事：第一，把“科研能力”拆成可测量的子任务，看清 Agent 的强项区在哪；第二，给出一套本地部署科研 Agent / 多 Agent 编排的最小可用环境；第三，设计一组可复现的测试用例，用你自己的课题数据去验证它到底行不行；第四，把接口调用、批量实验、成本控制和排错清单补齐。适合正在观望要不要把 Agent 引入科研工作流的博士生、博后、算法工程师和课题组技术负责人。

1. 核心能力速览：先看清“AI 做科研”覆盖的到底是什么

讨论这类话题最容易犯的错，是把“科研”当成一个整体能力去打勾或打叉。实际上科研是一串高度异构的任务串起来的流水线，每个环节对能力的要求完全不同。文献调研要的是检索召回和引用核验，实验实现要的是代码正确性和环境调试，跑实验要的是任务编排和失败重试，数据分析要的是统计判断，写作要的是逻辑组织和表述准确性，投稿回复要的是对审稿意见的理解和取舍。Agent 在这条流水线上的表现是断崖式不均匀的。

下面这张表是把公开讨论和实际可用工具链对齐后的速览，参数和结论都按保守口径写，具体表现必须以你自己的任务和本机环境测试为准。

这张表里最重要的一行其实是“强项任务”和“弱项任务”。很多争论之所以吵不出结果，是因为一方拿代码复现的成功率说事，另一方拿选题判断的失败案例反驳，两边讨论的根本不是同一件事。把任务切开之后，共识其实很容易达成：在执行层面，Agent 已经是可用的生产力工具；在判断层面，它还只是个提意见的助手。

还有一点值得强调：Agent 的“能力强”很大程度上来自它调用工具的能力，而不是它自己脑袋里的知识。一个能跑 shell、能读文件、能访问检索接口、能执行代码并看到报错的 Agent，和一个只能对话的模型，表现差距可能是数量级的。所以评估 Agent 的时候，别只看模型，要看它挂了哪些工具、工具返回的信息有多完整、失败了能不能自我修正。

2. 争议的实质：博士生的工作被拆成了哪些可自动化的部分

把一场关于“谁更强”的争论变成工程问题，最有效的办法是把博士生一天的工作拆细，然后逐项打分。拆完之后你会发现，那些被 Agent 追平甚至超过的部分，恰好是最枯燥、最重复、最不体现科研训练价值的部分；而那些真正决定科研成果质量的部分，Agent 基本插不上手。

2.1 选题与问题定义：Agent 目前无法替代

选题需要的是对领域现状的隐性理解、对哪些坑已经被踩过的记忆、对资源和时间的现实估算，以及一点点直觉。这些信息大部分不在公开文本里，而在导师的脑子里、在组会的争论里、在几次失败实验的教训里。Agent 读得到论文，读不到这些。它可以帮你把某个方向近三年的工作梳理成一张表，可以指出哪些子问题被反复提及，但它没法告诉你“这个方向再做两年大概率撞墙”。

更现实的问题是，Agent 给出的选题建议往往偏向“看起来合理但已经被做烂”的方向，因为它的判断来自已有文本的分布，而真正有价值的选题通常在这个分布的边缘。所以在选题环节，把它当文献地图用是合理的，当决策者用是不合理的。

2.2 文献调研：这是当前收益最明确的环节

文献调研是 Agent 目前性价比最高的落地点，原因很简单：这个任务的目标清晰、输入是文本、输出可校验。你需要做的往往是从一大堆积压的 PDF 里抽取出方法、数据集、评价指标、主要结论、局限性，然后横向对比。这件事人工做一周，Agent 加上人工复核可以压缩到一两天。

但这里有个必须警惕的坑：引用核验。Agent 生成的引用存在编造风险，包括作者名错、年份错、会议名错，甚至整篇文献不存在。所以正确的工作流是“Agent 抽取 + 人工或脚本核验”，绝不能是“Agent 直接写参考文献列表”。核验这一步不能省，也不能只靠模型自查，必须走外部数据源比对。

2.3 实验实现与调试：能力提升最明显的环节

这是过去一年多进步最快的地方。带代码执行能力的 Agent 可以读你的仓库、跑测试、看报错、改代码、再跑，这个循环它能自己转很多轮。复现一篇论文的基线实验、把别人的代码适配到自己的数据格式、修一个环境依赖冲突、把一段 notebook 改造成可批量运行的脚本，这类任务现在的完成度已经相当高。

但要注意“跑通”和“正确”是两件事。Agent 很擅长让代码不报错，但它可能用了一个等价性存疑的简化、跳过了一个关键的归一化步骤、或者把评估协议改成了更容易出好结果的那种。所以在实验实现环节，验收标准必须是“指标能对齐论文报告的量级”，而不是“代码没报错”。

2.4 实验编排与批量运行：工程能力的主场

跑一批超参搜索、批量处理上千条样本、失败自动重试、结果汇总成表，这类工作对 Agent 来说是舒适区，因为它本质上是工程任务。公开的机器学习 Agent 基准测试里反复出现的一个观察是：在较短的时间预算下，Agent 的表现相当有竞争力；但把时间预算拉长，让人类专家有充分时间迭代之后，人类会重新拉开差距。这个结论很值得玩味，它说明 Agent 的优势在“快速试错”，劣势在“深度思考后的方向调整”。

2.5 数据分析与写作：辅助可以，主导不行

数据分析环节，Agent 能快速生成统计脚本、画图、跑各类检验，但它对“这个结果意味着什么”的判断经常流于表面，容易把相关性说成因果，把不显著的差异描述成趋势。写作环节同理，它能帮你把实验记录组织成段落、把逻辑顺序理顺、把表达改得更清楚，但结论的措辞必须由人来定，因为那是要署名的。

把这几节合起来看，“AI 能力远超博士生”这句话的准确版本应该是：在文献结构化、代码复现、批量实验编排这三类任务上，Agent 的效率已经超过多数低年级博士生；在问题定义、结论判断、责任承担上，它还不是一个可比的角色。这个表述不刺激，但它是能站住的。

3. 适用场景与使用边界：什么课题组适合现在就上

搞清楚能力边界之后，适用场景其实很清楚了。第一类是计算密集型方向，比如机器学习、计算化学、计算生物学、遥感、金融工程，这些方向的实验可以在机器上闭环，Agent 的试错成本低、反馈信号明确。第二类是文献量巨大的方向，需要长期跟踪大量预印本，Agent 的信息压缩能力有明显价值。第三类是工程化程度高的团队，本身就有 CI、有测试、有实验管理平台，Agent 能直接接到现有流水线上。

反过来，有几类场景现在上 Agent 大概率是自找麻烦。湿实验为主的课题，Agent 没法替你移液和跑胶，它能做的只有实验记录整理和方案文档化。需要伦理审查和知情同意的人体相关研究，任何自动化环节都必须人工把关。还有一类容易被忽略：结论直接对外发布、涉及公共利益的课题，生成内容必须逐条人工核实。

3.1 合规与安全边界不能省

把 Agent 引入科研工作流，有几条线要提前划清楚。数据层面，未发表的实验数据、合作方提供的受限数据、涉及个人隐私的样本信息，不要随手贴进第三方 API，尤其是走公网服务的时候。代码层面，从公开仓库拉下来的代码要注意许可证，Agent 往往不看 LICENSE 就直接改，商用前必须人工过一遍。产出层面，AI 参与的程度要按你所在期刊和机构的要求如实披露，不能隐瞒。

还有一个很实际的风险：Agent 会自信地给出错误结论。它不会说“我不确定”，它会用很流畅的语言把一个错误的分析路径讲得头头是道。所以任何进入论文的结果，都必须有一条人工可复现的验证路径，比如固定随机种子重跑、换一套评估脚本交叉验证。这条规矩比任何工具选型都重要。

4. 环境准备与前置条件：本地跑科研 Agent 需要什么

先说明一点：科研 Agent 的部署门槛和图像生成模型完全不是一个量级。如果你走 API 模式，本地几乎不需要 GPU，一台能跑 Docker 的机器就够。只有当你需要本地跑开源基座模型、或者处理不能外传的数据时，才需要认真考虑显存。

4.1 通用检查清单

下面这份清单不绑定具体项目版本，按你实际选用的框架调整：

• 操作系统：优先 Linux（Ubuntu 系最省事），macOS 可用，Windows 建议 WSL2 或直接容器化。
• 运行时：Python 3.10 及以上是多数 Agent 框架的常见要求，Node.js 在部分前端和工具链里需要，具体版本看项目文档。
• 容器：Docker 与 Docker Compose，Agent 需要执行代码时，容器隔离几乎是必须的，别让它直接在宿主机上跑任意脚本。
• 网络与凭据：走 API 模式需要准备好模型服务的访问凭据，用环境变量注入，不要硬编码进代码。
• 磁盘：Agent 产生的日志、中间文件、拉下来的仓库很容易堆积，预留几十 GB 比较稳妥。
• 端口：Web 界面类工具通常占用一个本地端口，启动前先确认没被占用。
• GPU：仅本地推理时需要，显存需求取决于模型规模、量化方式和上下文长度，没有通用数字，需按实际环境测试。

4.2 凭据管理的最小实践

很多人图省事把 key 直接写进脚本，这在科研场景里风险不小，因为实验脚本经常会被分享给同组同学或者上传到仓库。稳妥的做法是用环境变量加.env文件，并且把.env加进.gitignore。

# .env 示例，实际变量名需按所用框架文档调整 MODEL_API_BASE=https://your-endpoint.example.com/v1 MODEL_API_KEY=replace_with_your_key AGENT_WORKSPACE=./workspace AGENT_LOG_DIR=./logs

# 启动前加载环境变量，避免写死在代码里 set -a source .env set +a # 确认变量已注入，不要打印完整 key python -c "import os; k=os.getenv('MODEL_API_KEY',''); print('key loaded:', bool(k), 'len:', len(k))"

这里特意用打印布尔值和长度的方式做校验，而不是直接 echo 出 key，就是为了避免凭据泄漏到终端历史或者日志文件里。这个习惯在团队协作里尤其重要，因为日志经常会被打包发给别人排查问题。

5. 安装部署与启动方式：从单 Agent 到多 Agent 编排

部署形态大致分三档，按你的需求选，不要一上来就上最复杂的。

5.1 第一档：命令行单 Agent

最轻的形态就是一个能读文件、能执行命令的 Agent 跑在终端里，你给它一个任务描述，它自己在工作目录里折腾。这类工具通常用 pip 或官方脚本安装，启动后绑定一个工作目录。优点是上手快、上下文干净；缺点是没有隔离，它执行命令的权限和你一样大。

# 通用模板：创建隔离环境并安装，包名需按实际项目替换 python -m venv .venv source .venv/bin/activate pip install --upgrade pip pip install <agent-package-name> # 建议在独立的工作目录里启动，避免它误改你的主仓库 mkdir -p workspace && cd workspace <agent-cli-command> --help

启动前一定要先跑--help看清参数，尤其是工作目录、模型配置、是否允许执行命令这几项。很多事故都是因为默认配置下权限过大导致的。

5.2 第二档：容器化部署

需要 Agent 执行不可信代码时，容器是底线。容器化的好处是文件系统隔离、依赖隔离、跑完直接销毁。下面是一个通用模板，镜像名和端口要按实际项目替换。

# docker-compose.yml 通用模板，镜像与端口需按实际项目调整 version: "3.8" services: agent: image: <agent-image>:<tag> container_name: research-agent ports: - "127.0.0.1:3000:3000" environment: - MODEL_API_BASE=${MODEL_API_BASE} - MODEL_API_KEY=${MODEL_API_KEY} volumes: - ./workspace:/workspace - ./logs:/logs working_dir: /workspace restart: unless-stopped deploy: resources: limits: memory: 16G

注意端口绑定写的是127.0.0.1:3000:3000，只监听本机，不要写成0.0.0.0，否则同网段任何人都能访问你的 Agent 界面，而它手里握着你所有的模型凭据。这一点在课题组共享服务器上特别容易出事。

# 启动与查看日志 docker compose up -d docker compose logs -f --tail=100 # 确认容器内环境变量已注入（不打印具体值） docker compose exec agent sh -c 'echo base=$MODEL_API_BASE; echo key_len=${#MODEL_API_KEY}'

5.3 第三档：多 Agent 编排

当你需要把任务拆给不同角色的 Agent 时，就要上编排框架了。常见的做法是定义一个规划者、一个执行者、一个审查者，规划者拆任务，执行者写代码跑实验，审查者检查结果是否符合要求。用状态图的方式描述流程是最直观的，也便于加人工审核节点。

# 多 Agent 编排的通用骨架，具体 API 需按所用框架文档调整 from typing import TypedDict, Literal class ResearchState(TypedDict): task: str plan: list[str] current_step: int artifacts: list[str] review_passed: bool def planner(state: ResearchState) -> ResearchState: """把大任务拆成可执行的小步骤""" # 实际实现中这里调用模型，产出结构化步骤列表 state["plan"] = [f"step-{i}" for i in range(3)] state["current_step"] = 0 return state def executor(state: ResearchState) -> ResearchState: """执行当前步骤，产出文件或指标""" step = state["plan"][state["current_step"]] state["artifacts"].append(f"output/{step}.json") return state def reviewer(state: ResearchState) -> ResearchState: """检查产物是否达标，不达标退回执行""" state["review_passed"] = True state["current_step"] += 1 return state def route(state: ResearchState) -> Literal["executor", "planner", "done"]: if state["current_step"] >= len(state["plan"]): return "done" if not state["review_passed"]: return "executor" return "planner"

这段代码是骨架，重点在结构而不是具体实现：一定要有一个 reviewer 节点，并且 reviewer 不通过时要能退回重做。没有审查环节的多 Agent 系统，本质上是在放大错误——第一个 Agent 编了个不存在的结论，后面的 Agent 会基于这个假结论继续往下推，最后产出一份看起来很完整、实际全是幻觉的报告。

6. 功能测试与效果验证：用你自己的课题数据去测

这一节是全文最该照着做的部分。别人的评测分数对你参考价值有限，因为你的任务分布、你的代码库、你的数据格式都不一样。下面给五个测试方向，按从易到难排，建议按顺序做，前一个不过关就别急着做下一个。

6.1 测试一：文献结构化抽取

目的是看它能不能稳定地从 PDF 里抽出结构化字段。准备十篇你已经读过的论文，让 Agent 输出一个表格，字段包括方法名、数据集、评价指标、主要结论、局限性。判断标准不是“格式对不对”，而是“字段值能不能和原文对上”，尤其是数字和数据集名称这类硬信息。

常见的失败模式有三种：把相关工作里的方法当成论文自己的方法；把实验设置里的数据集张冠李戴；局限性部分直接编一句通用的话。前两种属于理解错误，第三种属于偷懒。遇到这些情况，先检查你给的提示里有没有明确要求“无法确定的字段填 UNKNOWN”，这个约束能显著降低编造率。

6.2 测试二：引用核验

这个测试必须单独做，因为它直接关系到学术诚信。让 Agent 生成一段带引用的文献综述，然后逐条核验：作者、年份、标题、发表 venue 是否都能在公开数据库里查到。预期结果是会有一定比例的条目存在问题，这是正常的，关键是你要有一套核验流程。

稳妥的做法是写个小脚本，把 Agent 输出的引用条目解析成结构化字段，然后逐条去公开检索接口比对，比对不上的标记出来人工确认。整个过程必须留日志，因为万一后面出问题，你需要知道是哪一步引入的错误。

6.3 测试三：代码复现任务

选一篇有公开代码的论文，把仓库克隆下来，让 Agent 尝试在干净环境里跑通基线实验。测试时重点观察四件事：它能不能自己解决依赖冲突、能不能读懂 README 里的运行说明、遇到报错会不会盲目改代码、跑完之后能不能自己核对指标。

判断成功的标准要写清楚：不是“进程正常退出”，而是“在指定数据集上跑出的指标与论文报告值处于同一量级”。如果差得远，要能定位到是数据预处理、评估脚本还是超参设置的问题。这个测试最能体现 Agent 的真实工程水平，也最容易暴露它在“看起来跑通了”和“确实跑对了”之间的模糊地带。

6.4 测试四：批量实验编排

准备一个有二十组左右配置的超参搜索，让 Agent 负责生成配置、提交任务、监控状态、失败重试、汇总结果。观察点是它设计的任务编排是否合理：有没有做并发控制、有没有记录每组配置的完整参数、失败重试有没有上限、结果文件命名是否可追溯。

这里最常见的坑是无限重试和结果覆盖。Agent 有时候会把失败的任务反复重跑，把日志刷爆；也可能用同一个输出路径反复写，最后只剩最后一组的结果。所以测试之前先把输出目录规范和重试上限写进任务描述里，让它照着做，而不是让它自己发挥。

6.5 测试五：长上下文与整篇论文组织

给它一份完整的实验记录，让它组织成论文的方法和实验章节草稿。这个测试主要看两点：一是长上下文下信息有没有丢失，比如前面提到的关键设置后面有没有用错；二是逻辑组织是否合理，有没有出现前后矛盾。

预期结果应该是：结构和表达可用，但结论措辞需要大幅修改。如果它写出来的东西你几乎不用改就能投，那反而要警惕，可能是它在套用常见表述而忽略了你实验的独特之处。判断标准建议定为“能省掉从零开始写初稿的时间，但每一句涉及结论的话都要人工确认”。

7. 接口 API 与批量任务：把 Agent 接进现有流水线

单次对话式的使用方式很难规模化，真正有价值的是把 Agent 变成一个可编程的服务，接进你现有的实验管理流程。多数 Agent 框架都提供 HTTP 接口，路径和参数各不相同，下面给的是通用调用模板，实际路径需要按项目文档替换。

# 通用调用模板，接口路径与字段需按实际项目调整 curl -s -X POST "http://127.0.0.1:3000/api/task" \ -H "Content-Type: application/json" \ -H "Authorization: Bearer ${AGENT_TOKEN}" \ -d '{ "task": "run_baseline", "repo": "/workspace/repo", "config": "configs/baseline.yaml", "timeout_sec": 3600, "max_retry": 2 }'

import os import time import requests BASE = os.getenv("AGENT_BASE", "http://127.0.0.1:3000") TOKEN = os.getenv("AGENT_TOKEN", "") def submit_task(payload: dict, poll_interval: int = 15, max_wait: int = 7200) -> dict: """提交任务并轮询结果，失败时按上限重试""" headers = {"Authorization": f"Bearer {TOKEN}"} resp = requests.post(f"{BASE}/api/task", json=payload, headers=headers, timeout=60) resp.raise_for_status() task_id = resp.json()["task_id"] deadline = time.time() + max_wait while time.time() < deadline: r = requests.get(f"{BASE}/api/task/{task_id}", headers=headers, timeout=30) r.raise_for_status() data = r.json() if data["status"] in ("succeeded", "failed"): return data time.sleep(poll_interval) return {"task_id": task_id, "status": "timeout"} if __name__ == "__main__": task = { "task": "run_experiments", "config_dir": "/workspace/configs", "output_dir": "/workspace/results", "max_retry": 2, } print(submit_task(task))

批量任务的设计有几个要点值得单独说。第一，输出目录必须按任务 ID 或时间戳隔离，绝不能共用同一个路径。第二，每个任务都要有独立的日志文件，出问题能单独回溯。第三，重试次数必须设上限，并且重试时要记录原因。第四，如果任务涉及付费接口，必须做预算控制，否则一个死循环能把额度烧光。

{ "batch": { "input_dir": "./configs", "output_dir": "./results", "concurrency": 2, "max_retry": 2, "retry_backoff_sec": 30, "budget_limit_usd": 20, "log_per_task": true } }

这份配置里concurrency设成 2 而不是开满，是有意的。批量实验跑得快没用，如果同时打满接口导致大量 429 或者把内存吃穿导致进程被杀，整体吞吐反而更低。先从低并发压测，测出稳定吞吐再逐步调高，这个过程比直接抄别人的参数靠谱得多。

8. 资源占用与性能观察：真正烧钱的地方在哪

科研 Agent 的成本结构和图像模型完全不同。图像模型你关心显存占用和单张耗时，Agent 你更该关心 token 消耗、上下文长度、工具调用次数和任务重试率。显存只有在本地跑开源基座模型时才成为瓶颈。

8.1 观察哪些指标

第一个指标是单任务 token 消耗。Agent 和普通对话最大的区别是它会反复读文件、反复执行命令、反复把结果塞回上下文，所以 token 消耗往往是任务复杂度的超线性函数。第二个指标是上下文峰值，长任务很容易把窗口撑满，触发截断后行为会变得很奇怪。第三个指标是工具调用次数，如果一个简单任务调了几十次工具还没收敛，基本可以判定它卡在某个循环里了。第四个指标是重试率，重试率高说明任务描述或环境有问题，不是模型不行。

观察手段上，建议在框架层面把每次调用的输入长度、输出长度、耗时、工具名都记进结构化日志，然后按任务 ID 聚合。这比事后翻终端输出高效得多。

8.2 怎么把成本压下来

最有效的手段是缩小上下文。不要把整个仓库塞给它，让它先列目录、再按需读文件。其次是固定工具集，工具越多它越容易乱选，把常用工具留下、冷门工具去掉往往能提升稳定性。第三是缓存，同一份文献解析结果没必要每次重算，落盘缓存下来。第四是分阶段，把一个大任务拆成几个小任务分别跑，每个阶段有明确的输入输出，失败时只重跑出问题的那一段，而不是从头再来。

本地推理的话，显存占用取决于模型规模、量化位宽和上下文长度三个变量。降低上下文长度、用量化版本、减小并发，都能把显存压下来，但每一项都有代价，需要你按实际任务权衡。这里不给具体数字，因为同一份模型在不同推理框架、不同 batch 设置下差别很大，写死一个数反而误导。

8.3 避免进程残留和端口占用

Agent 类任务很容易留下后台进程：它启动的服务没关、跑起来的训练脚本被中断、容器没清干净。这些残留会持续吃显存和端口，导致下一次启动莫名其妙失败。建议在脚本里显式做清理，并且养成跑之前先看一眼占用情况的习惯。

# 启动前检查端口与 GPU 占用 ss -lntp | grep -E ':(3000|7860|8080)' || echo "ports free" nvidia-smi --query-gpu=index,memory.used,memory.total --format=csv # 任务结束后清理容器与残留进程 docker compose down --remove-orphans pkill -f "agent-worker" || true

9. 常见问题与排查方法

Agent 类项目的报错信息往往很长，但真正有用的就那一两行。下面这张表覆盖了实际使用中最高频的问题，按现象查比按报错查更快。

这张表里最值得单独展开的是“文件被误改”。很多人第一次用带执行能力的 Agent 时，习惯在自己正在开发的仓库里直接跑，结果它为了“修好报错”改了几个不该动的文件。稳妥的做法是给它一份克隆出来的副本，主仓库挂载为只读，等它改完再人工 review 后合并。这个流程多花十分钟，能省掉几小时的恢复时间。

10. 最佳实践与使用建议

用 Agent 做科研，工程习惯比工具选型更重要。这里有几条是被反复验证过的。

第一，永远先跑小样本。不管是文献抽取还是批量实验，先拿三条数据跑通全流程，确认输入输出格式、日志位置、失败处理都符合预期，再放开到全量。全量跑一半发现格式不对，重来的成本远高于先做小样本验证。

第二，把提示和配置当成代码管理。任务描述、工具集、参数、终止条件都应该进版本控制，因为效果好坏往往取决于这些细节，而人是记不住两周前那次成功用的什么配置的。每次效果有明显变化时，能 diff 出改了什么，这是可复现性的基础。

第三，目录结构要分清楚。输入、输出、日志、缓存、临时文件，各自独立目录，不要混在一起。Agent 会到处写文件，结构不清的话跑两天你自己都找不到结果在哪。

第四，人工审核节点必须显式存在。不要指望 Agent 自己判断“这个结论能不能写进论文”，把审核做成流程里的一个必过环节，不通过就打回。审核的标准也要写下来，不然每次标准都在变。

第五，涉及第三方数据的场景要格外小心。合作方给的未发表数据、含个人信息的样本、受限许可的代码，处理之前先确认允许的处理方式。科研场景的数据合规不是形式主义，出了问题影响的是整个课题组。

第六，产出要能追溯。每一份由 Agent 参与生成的中间产物，都应该能追到用了哪个模型、什么提示、哪个版本的脚本、什么时候跑的。这件事在投稿返修阶段价值极高，因为审稿人问“这个数字怎么来的”的时候，你需要能当场答出来。

第七，别把 Agent 的输出当成事实。它是个高效的草稿生成器和一个耐心的调试助手，不是事实来源。所有进入论文的数字、引用、结论，都要有人工可复现的验证路径。

11. 回到那个问题：能力边界在哪，该怎么用

“AI 做科研的能力已经远超博士生”这句话，如果限定在“给定明确目标的执行类任务”这个范围内，是有相当事实基础的。文献结构化、代码复现、批量实验编排这几件事，Agent 的速度和稳定性确实已经超过多数人的手动操作。但这个限定条件不能省，因为一旦离开这个范围，比如问它“这个方向值不值得做”“这个反常结果意味着什么”“这个结论敢不敢写进摘要”，它的表现就会从“能干”迅速滑到“会编”。

这场讨论里最有价值的共识其实不是谁更强，而是分工应该怎么划。把 Agent 放在执行层，人留在判断层，是目前性价比最高的组合。它能帮你把原本要一周的文献整理压到两天，把复现基线的调试时间砍掉大半，把二十组超参实验的编排变成一段脚本；但它替你决定不了研究问题，也承担不了结论的责任。

如果你准备开始试，建议的顺序是：先做文献结构化抽取，这是门槛最低、收益最直接的一步，跑通之后你对它的能力边界会有直观感受；然后做一次代码复现，这一步最能暴露工程能力的真实水平；最后再考虑把批量实验接进流水线。最容易踩的坑有三个：一是不做引用核验就直接用生成的参考文献，二是让 Agent 在正在开发的仓库里裸奔执行命令，三是不设预算上限导致接口费用失控。这三个坑避开了，后面的路会顺很多。

往下可以继续扩展的方向也不少。比如把 Agent 接到你课题组现有的实验管理平台上，让它自动读取实验队列、失败重试、生成日报；比如给文献库建一套本地索引，让检索走自己的库而不是靠模型记忆；再比如把审查节点做成规则加模型的双重校验，规则负责硬性检查（字段完整性、数值范围、引用可查），模型负责软性检查（逻辑一致性、表述准确性）。这些改造都不复杂，但能把 Agent 从“偶尔好用的玩具”变成“每天都会开的生产工具”。建议把这篇收藏备用，等你真正开始搭环境的时候，第 4 节的检查清单和第 9 节的排查表会反复用到。