终端不应掌控工作

# 超越终端会话的持久化智能体执行 · vincent 来源：https://lezli01.is-a.dev/vincent/docs/why/the-terminal-should-not-own-the-work.html // docs/why/the\-terminal\-should\-not\-own\-the\-work\.md文档在线 ## 终端不应掌控工作 终端是启动进程的好地方，却是存储该进程真实状态的糟糕场所。 当智能体任务绑定在某个终端标签页时，该标签页就成了意外的控制平面。关闭它可能中断工作，丢失回滚记录可能抹除有用的解释说明。重新打开项目意味着需要重新构建运行过的内容、修改的分支，以及任务是等待中、已完成还是静默卡住的状态。任务运行时间越长，这种安排就越显脆弱。 Vincent 将控制权转移至后台守护进程。该守护进程掌管任务状态、工作流执行、智能体进程、调度、数据库和 Git 工作树。TUI（终端用户界面）、CLI（命令行界面）和 API 都是状态的客户端。关闭任何客户端都不会影响其背后的工作。 这种架构选择带来的影响显而易见：我可以启动任务、关闭 TUI、用终端处理其他事务，稍后返回时依然能获得相同的状态与历史记录。多个客户端可同时检查同一守护进程而不会产生写入冲突。即使无人打开控制面板，调度器仍能按照优先级和并发限制接入任务。 持久性也改变了中断处理方式。Vincent 在执行状态转换前会先持久化记录。若守护进程在某个步骤中途停止，重启恢复机制会记录此次中断尝试，在停止任何孤儿进程前进行验证，并在不消耗失败重试次数的情况下重新执行该步骤。系统不会假装进程能在机器重启后存活；它使中断显式化，并从已知状态恢复。 将守护进程安装为用户服务后，这种模型可跨登录会话延续。操作系统启动控制平面，终端则回归其本位——仅仅是观察工作的可选窗口之一。 这一点至关重要，因为智能体编码正日益成为一种负载工作而非对话过程。任务可能受配额、审批门控、重试机制、子分支及外部检查的影响而等待。其生命周期不应与启动它的界面生命周期绑定。 终端可以展示工作，但它不应掌控工作。 --- 返回《为何 Vincent 如此出色》(https://lezli01.is-a.dev/vincent/docs/why/) · 理解守护进程(https://lezli01.is-a.dev/vincent/docs/getting-started/concepts.html#the-daemon)