FAROS 自动研究运行时
以蓝图驱动的自助研究运行时，将AI研究从想法、实验、论文到评审全流程自动化。
证据显示：存在包信任验证（TRUST.json、签名、完整性校验）、回滚机制（备份/回滚）、以及外部效果控制（沙箱、执行后端）。扣分：缺少最小权限原则的明确说明，用户确认机制不明确，数据流透明度有限，敏感数据处理未详细说明，依赖安全未审计，外部效果未全面评估，来源归属仅部分（发布者未验证）。
证据显示：测试覆盖了代理循环、失败分类、命令发现、修复服务等，自一致性较好。扣分：依赖可用性未验证（如LLM提供者），失败消息部分存在但不够全面。
证据显示：面向LLM研究场景，有蓝图、能力、配置文件，支持多种提供者。扣分：触发精度（如命令发现）有限，环境适配未全面测试。
证据显示：有README、开发指南、TODO、安装说明、示例。扣分：缺少许可证，版本控制/变更日志不明确，维护责任未明确。
证据显示：输出工件（论文、代码、审查）可用，边际价值高（自动化研究流程）。扣分：成本效益未评估（如LLM成本）。
证据显示：有测试和验证规则，但声明可追溯性有限，跨来源佐证不足，事实与推断分离不明确。
- 发布者身份未验证，需谨慎对待。
- 许可证缺失，使用前需确认法律条款。
- 依赖安全未审计，特别是LLM提供者。
- 敏感数据处理细节不足，需检查配置。
- 成本效益未评估，LLM调用可能产生高费用。
这个 Agent 能做什么，适合哪些场景？
FAROS 是一个面向 LLM 领域的研究工作流运行时，通过蓝图（Blueprint）、能力（Capability）、配置文件（Profile）与提供方（Provider）四大抽象，将研究自动化视为运行时问题而非单个 Agent 提示词堆栈。当前版本（1.1.0-rc1）提供了首个可运行基线 FAROS-LLM，完整实现了 '想法 -> 实验 -> 论文 -> 评审' 的闭环。后端采用 Python (FastAPI) 构建，提供 REST API 进行运行管理、蓝图与配置文件加载，以及基于文件的事件、工件与内存持久化。首个蓝图 ml_paper 已包含四个能力：idea_refinement、experiment、paper_drafting 和 reviewer_simulation。论文生成支持 venue-aware 的 LaTeX 模板（ICML、NeurIPS、ICLR、ACL 等），并具有编译失败回退到简化 PDF 的机制。前端为 Node.js 应用，但当前后端 API 已足够独立使用。项目定位为研究自动化平台的第一阶段，尚未实现 DAG 调度、真实实验执行与评估循环等完整特性。
FAROS 运行时负责加载蓝图与配置文件、注册能力与提供方、编排执行流程，并持久化运行事件与工件。具体流程为：通过 POST /api/faros/runs 创建运行，指定 blueprintId (如 ml_paper) 和 profileId (如 faros_llm)，可选用 plan 模式只生成计划。运行后，idea_refinement 生成想法候选并排序，experiment 产生代码项目脚手架与实验记录，paper_drafting 生成 venue-aware 的 LaTeX 项目与 PDF，reviewer_simulation 输出结构化的评审报告与行动项。所有工件以文件形式存放在 DATA_DIR 目录中。系统提供 /api/faros/blueprints、/api/faros/profiles、/api/faros/runs/{run_id}/events 等 REST 端点进行管理。LLM 提供方通过环境变量或 provider_config.json 配置，支持包括 minimax 在内的多个提供方。
- 研究团队希望自动化生成领域论文初稿，并使用 LaTeX 模板输出符合会议格式的 PDF
- AI 研究者需要快速验证研究想法，通过 FAROS 的 plan 模式生成执行计划而不实际运行 LLM
- 需要模拟同行评审，对论文草稿进行结构化审查并生成改进建议
- 希望在研究流程中加入实验代码脚手架，为后续真实实验做准备
- 开发者希望以可编程方式集成研究自动化，通过 REST API 创建运行并获取工件
这个 Agent 有哪些优点和局限？
- 将研究自动化抽象为运行时，蓝图、能力、配置、提供方分层清晰，便于扩展新领域
- 完整实现了想法生成到评审的闭环，且论文生成支持多种会议 LaTeX 模板
- 提供 REST API 和 plan 模式，便于集成与验证，降低运行成本
- 基于文件的持久化，无需外部数据库即可运行
- 当前仅支持 LLM 域，未实现真实实验执行与评估，实验脚手架仅为占位
- 线性执行流程，缺少 DAG 调度和并行编排，复杂流程受限
- 提供方配置依赖环境变量或配置文件，切换提供方需重新配置
- 文档宣称支持多种提供方，但代码证据仅明确 minimax，其他提供方支持待验证
- 缺少前端控制台，管理依赖 API
如何安装或部署这个 Agent？
安装依赖：Python 3.11+ 与 Node.js 18+；需要 latexmk 和 pdflatex 用于 PDF 编译。后端进入 backend 目录运行 pip install -r requirements.txt；前端进入 frontend 目录运行 npm install。需要配置 LLM 提供方的 API 密钥，可通过环境变量或 backend/data/provider_config.json 设置，注意不要提交真实密钥。
如何使用这个 Agent？
启动后端：在 backend 目录执行 uvicorn app.main:app --host 127.0.0.1 --port 8005 --reload；启动前端：在 frontend 目录执行 npm run dev。确认系统就绪：访问 GET /api/system/version，确保 llm.configured=true。创建运行：使用 curl 示例 POST /api/faros/runs，携带 blueprintId、profileId、executionMode 和 inputs。例如：curl -X POST http://127.0.0.1:8005/api/faros/runs -H 'Content-Type: application/json' -d '{"blueprintId": "ml_paper", "profileId": "faros_llm", "executionMode": "plan", "inputs": {"seedQuery": "Improve CPU efficiency in LLM workflows", "paperType": "system", "targetVenue": "generic"}}'。然后通过 GET /api/faros/runs/{run_id} 查看运行状态与工件。