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

返回

Kevin Riedl

9 分钟 阅读 · 2026年9月3日
最近审核 2026年9月3日

下一篇

生命周期更新，核查于 2026 年 10 月 22 日：下文架构评测保留 9 月 3 日的基线。Feynman 此后缩小了功能范围，watch、jobs 和 rank 已在 0.3.49 之后移除。安装和可用流程应以当前版本文档为准。本次更新并非对新运行时的性能实测。

Feynman 支持有来源的研究、撰写、引用检查、论文与代码对照审计及复现规划。输出应作为可审阅草稿，由专业人员负责证据质量和最终验收。

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

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

如果需要的是 Web 检索与证据层，而不是完整研究工作流，我们的 Wigolo 评测会分析无 Key 多引擎搜索、本地缓存、来源定位、AGPL 与生产边界。

Feynman 是什么？

Feynman 是基于 Pi、采用 MIT 许可的研究 CLI。官方 README 描述了当前研究流程。以前独立的论文排名和定期 Watch 命令已不再属于该接口。结果与来源记录需要与其他研究文件相同的访问和保留控制。

比起四个 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 会自动定期运行吗？

不会。官方发布说明指出，watch 和 jobs 依赖 Feynman 未提供的调度器，已在 0.3.49 之后移除。团队如需定期研究，必须在这些已移除命令之外安排调度、凭据、预算和审阅。承诺持续监控前，应验证真实的定期运行。

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 并重新检查当前文档。