Feynman 评测：这款开源 AI 研究 Agent 适合团队吗？

Feynman 是目前将 Deep Research 变成可审计终端工作流的较完整开源尝试之一。输入一个主题，它可以搜索论文、网站和代码库，将任务分给四个专职 Agent，撰写有来源的简报，检查引用，对照论文与代码，计划复现实验，并持续跟踪某个领域。

我们在 2026 年 9 月 3 日检查了公开代码与文档。结论是：Feynman 值得技术研究团队试点，但“全本地”是一种可选架构，不是每个工作流的默认事实。模型调用、搜索服务和云 GPU 仍可能让数据离开本机，并带来用量成本。引用核验能降低风险，但不能替代判断证据是否充分的专家。

本文专门承接“Feynman 评测”和“开源 AI 研究 Agent”意图。LangChain Deep Agents 评测解答通用 Agent Harness 选型，Agent Reach 评测关注低成本来源访问，LLM-as-a-Verifier则关注轨迹评分。这样的分工可以避免品牌工具评测与广义架构指南相互竞争。

Feynman 是什么？

Feynman 是一款采用 MIT 许可证、基于 Pi Agent Runtime 和 alphaXiv 的 Research-first CLI。官方 README列出了 Deep Research、文献综述、论文排名、撰写、同行式审阅、代码审计、实验复现、ML Recipe 与定期 Watch 等工作流。结果写入本地项目目录，重度来源研究还会生成 Provenance 工件。

比起四个 Agent 的数量，工作流更重要。Feynman 将计划、中间研究、草稿、核验笔记与最终结果保存为文件，让团队可以审阅中间状态，也能在长任务失败后恢复。敏感研究笔记因此必须纳入访问、保留与备份政策。

Feynman Deep Research 如何工作？

它不会一开始就放出一群 Agent。Deep Research 工作流会先写计划并等待批准。窄问题由主 Agent 负责，广泛调研才可并行分工。随后，系统提取方法、结果与限制，区分共识与分歧，最后核对每条陈述。

1. 先计划问题。在消耗模型预算前写清子问题、来源策略、任务台账和验证日志。
2. 选择规模。窄问题不必并行，广调研才分给多个 Researcher。
3. 提取而不只是摘要。记录方法、结果、局限与出处。
4. 呈现冲突。不把分歧硬写成一个整齐答案。
5. 交付前验证。重新打开来源，删除或标记无支持的陈述。

除了文献综述，Feynman 还能做什么？

Feynman 真的能全本地运行吗？

它可以连接本地模型，但普通研究仍要访问外部来源。独立安装器文档说明，预构建 Bundle 携带固定 Node.js Runtime，并在替换现有安装前验证 SHA-256。也可以通过 npm 安装。对供应链敏感的团队应先阅读脚本、固定 Release，并核对公布的校验和。

设置指南支持托管 Provider、Amazon Bedrock、LM Studio、LiteLLM、Ollama 和 vLLM。本地模型可以让 Prompt 与推理留在自有基础设施。论文搜索、Web Retrieval、alphaXiv、托管 Parser 与云计算仍是网络边界，除非你明确替换或关闭它们。

• 研究 Prompt 发到了哪里？
• 哪个 Provider 收到 URL、文档、代码或搜索词？
• 抓取页面缓存在哪里，保留多久？
• Credential 与 OAuth Token 存在哪里？
• Telemetry 是否离开本机？

“在终端里运行”只是界面描述。“所有数据都留在本地”才是架构声明。必须用实际 Provider 和搜索配置验证后者。

Feynman 能消灭虚假引用吗？

不能，但它比“长得像引用”却没有验证的文本提供了更好的失败边界。Verifier 应该打开每个 URL，定位支持段落，将 Claim 分类为有支持、过度推断、矛盾或无支持，并删除无法溯源的事实陈述。

但仍有三个局限：可访问的 URL 可能是弱证据，模型可能漏掉方法学缺陷，搜索也可能漏掉改变结论的关键论文。应把最终报告当成可审计草稿。我们的AI Agent 评测与 Sandbox 检查清单说明了如何补上确定性检查、对抗用例与人工批准。

Feynman 能审计和复现论文吗？

代码审计工作流会从论文中提取具体 Claim，然后在关联公开代码库中寻找配置、训练和评估行为，用文件路径报告不一致、缺失实现和可复现性风险。它无法检查私有训练代码、不可用数据或未记录的人工步骤。

复现工作流会列出需求、实验 Recipe、未说明细节、风险和成功标准。只有用户明确选择本地、隔离环境、Docker、Modal、RunPod 或只做计划后，它才会执行。这个批准边界很重要，因为复现可能下载不可信代码、处理受许可限制的数据，并消耗真实 GPU 预算。

只有预定检查真正通过，且脚本与原始输出被保留时，才应该使用“已复现”。一份看起来合理的计划不是复现。

研究 Watch 会自动定期运行吗？

只有实际可用的 Scheduling 能力存在时才会。Watch 文档明确说明，Feynman 总会生成基线与后续计划，但只在 Scheduler Tool 可见时建立定期任务。否则它会记录缺口并给出下次手动刷新的 Prompt。

Feynman 的真实成本是什么？

软件采用 MIT 许可证，因此没有 License Fee。但一份被接受的研究报告至少还有五类成本：

• 模型推理：主 Agent、并行 Researcher、Reviewer、Writer 与 Verifier 都会消耗 Token 或本地计算。
• 搜索与提取：托管搜索、文档解析和 Grounding 可能按请求计费。
• 实验计算：本地 GPU 时间、云 GPU、存储与数据传输可能成为主要成本。
• 人工审阅：专家需要处理不确定证据与高风险建议。
• 运维：版本固定、Credential、保留策略、监控、Provider 变更与失败处理都需要 Owner。

正确分母是每份被接受的简报或每个通过验证的实验，而不是每次模型调用。一份需要两小时高级审阅来修复的便宜报告，其实很贵。

哪些团队适合 Feynman？

一个两周 Feynman 试点计划

1. 选择可重复的研究问题。最好已有可信人工简报与已知必找来源。
2. 事先固定验收标准。测量必找来源召回率、无关来源、Claim 支持、审阅修正与批准时间。
3. 固定 Release 与模型。记录版本、模型、搜索路由、Prompt 和检索日期。
4. 先不执行实验。先验证发现、综合与引用，再授予代码或 GPU 权限。
5. 加入对抗主题。放入冲突论文、死链接、不完整代码与诱人的无支持 Claim。
6. 审查数据流。列出 Provider、Credential、Cache、Retention 与所有外发请求。
7. 测试一次论文审计。让工程师直接在代码库中抽查 Match 与 Mismatch。
8. 测试一份有界复现计划。在支出计算费前让专家检查假设。
9. 统计全部成本。Token、搜索、GPU、失败任务与审阅分钟都要计入。
10. 预先设置扩大门槛。只有时间或证据覆盖改善，且引用支持和控制不下降时才扩大。

研究边界

信息截止 2026 年 9 月 3 日，来自 Feynman 公开代码库、许可证与官方工作流文档。本文是独立架构与采购评测，不是赞助内容、安全审计或受控 Benchmark。我们没有安装 Feynman、提交私有文档、连接付费 Provider 或执行 GPU 复现。项目迭代很快，采用前应固定 Release 并重新检查当前文档。