总览
核心不是“会聊天”，而是“如何把终端智能体做成一个长期运行的产品内核”
当前可见源码显示，这个仓库把启动、REPL、命令、工具、权限、任务、扩展、远程和状态治理全部放进同一套终端运行时。最关键的判断是：query() 才是真正共享的执行内核；REPL 和 SDK/headless 只是进入它的两条不同壳层。
你会在这里学到什么
分析边界
事实边界：当前目录不是完整 Git 仓库，只能确认
src/ 源码树与我们生成的分析产物。根级依赖、CI、完整测试结构、发布脚本在当前快照中不可见。
- 已确认使用 TypeScript / TSX、Bun、React/Ink、Zod、Anthropic SDK、MCP SDK。
- 已确认 REPL 交互路径直接调用
query()，而QueryEngine更偏 SDK/headless façade。 - 已确认存在命令系统、工具系统、任务系统、权限系统、插件、skills、MCP、远程会话。
- 未确认完整构建命令、完整测试组织、完整 CI 流水线。
系统轮廓
最重要的不是文件夹，而是这四条支撑性判断：
main.tsx、setup.ts、init.ts共同定义启动边界，而不是单一入口函数包办一切。query.ts是共享执行内核；QueryEngine和 REPL 只是两种进入方式。toolExecution.ts与useCanUseTool.tsx说明工具调用本质上是“可审批的执行协议”。AppState和ToolUseContext是系统最关键的两个跨层粘合抽象。pluginLoader.ts、mcp/client.ts、loadSkillsDir.ts不是同类机制，而是三条扩展轴。
建议优先回答的五个问题
1. 程序为什么要拆成
main.tsx、setup.ts、entrypoints/init.ts 三段启动？2. 为什么 REPL 不走
QueryEngine，而是直接调用 query()？3.
ToolUseContext 为什么会变成一个重量级应用协议，而不是轻量参数对象？4. 为什么权限系统必须跨 settings、tool execution、hooks、classifier 和 UI 多层协作？
5. 插件、MCP、skills 为什么必须分三条扩展通路，而不是并进一个统一插件接口？