第 1 章 点火：先让系统活过来

第一次打开 EvoScientist，很多人都会有一种不安：这套系统看起来很强，但我到底该从哪一步开始，才不会一上来就陷入细节泥潭？

如果费曼站在你旁边，他大概会说：别急着背结构图，先点亮灯泡。灯亮了，你再问电流从哪里来，就不再是空想。

所以这一章，我们只做一件事：让 EvoScientist 在你的机器上“有生命地跑起来”，并且你知道它为什么活着。

当你在终端输入 EvoSci，看上去只是一条命令，实际上系统已经开始分工。EvoScientist/cli/__init__.py 先接住入口，把命令路由到 Typer 应用；再往下，真正的“中枢”在 EvoScientist/EvoScientist.py。这个文件最重要的设计不是“功能多”，而是“克制”：它把模型、MCP、后端这些重组件放到真正需要时才初始化。也正因为如此，EvoSci config list 这类轻命令会非常快，而进入完整会话时才会有明显启动成本。

这背后的思想很朴素：不要在你还没做实验时，就把整座实验室都通电。

接下来你会碰到第二个关键点：工作区。EvoScientist/paths.py 默认把你当前目录当作 WORKSPACE_ROOT，并在其下推导 memory/、skills/、runs/、media/。这不是“目录规范”那么简单，而是系统记忆、技能、产物的边界线。你从 A 目录启动和从 B 目录启动，系统看到的是两张不同的实验台。很多“为什么这次不一样”的困惑，根源都在这里。

真正的点火流程并不复杂：先 EvoSci onboard 配好模型和密钥，在目标项目目录启动会话，然后给一个小而明确的任务，观察它是否能稳定走完一次工具调用链。你此时不必追求“答案多聪明”，你要看的是链路有没有打通：能启动、能思考、能调用、能返回。

你还会注意到一个很有安全感的细节：系统并不是“一错就死”。middleware/tool_error_handler.py 会把工具异常收束成 ToolMessage(status="error")，交回给 agent 继续决策；当任务信息不足时，AskUserMiddleware 会通过 interrupt() 主动向你确认。前者让系统遇错不断电，后者让系统不靠猜测硬冲。

到这一步，你已经完成了从“安装一个工具”到“启动一个研究伙伴”的跨越。你并不需要背下全部源码，但你已经抓住了第一性原理：入口如何被接住，状态如何被落地，错误如何被驯服。下一章，我们就把这束点亮的火，变成稳定燃烧的炉子。