上一篇讲了 covo-agent 选 Go 的原因，这一篇回到功能本身。covo-agent 之所以全能，除了双模式之外，还有另一个维度：covo-agent 的三种用法。同一个 Agent 内核，可以根据场景以不同形态运行。
交互式covo-agent 的默认启动方式是交互式 TUI。
在这种形态下，Agent 以流式方式输出内容，工具的执行状态实时可见，用户可以用鼠标进行选择，随时切换会话历史、选择模型、更换主题，Shell 补全也会生效。适合需要人在回路的场景——边看边做、随时干预、即时纠偏。这也是日常使用中最自然的形态。
脚本第二种形态是 oneshot，即"单次问答"。通过 -z 或 --oneshot（别名 --pipe）传入一个 prompt，Agent 执行后将结果输出到标准输出，随即退出。
这一形态的关键价值在于可组合性。输出可以直接作为脚本的输入，也可以配合 --json 得到结构化的结果，便于后续程序解析。此外，oneshot 支持从标准输入读取内容，因此可以很自然地嵌入管道：
covo-agent -z "总结当前仓库"
covo-agent -z "审查未提交的修改" --json对于"让 Agent 成为工作流中的一个环节"这类需求，oneshot 是更合适的入口。
无人值守第三种形态是 headless，即无头模式，完全脱离 TUI。
特点在于"受控"：可以指定工具白名单（--tools）与黑名单（--disallowed-tools），限定 Agent 只能使用哪些工具；可以设置最大轮次（--max-turns）与超时时间（--timeout），防止无限运行；还可以通过 --allow 与 --deny 配置基于 pattern 的权限规则，例如只放行特定形式的命令：
covo-agent --headless \
-z "找出测试失败的原因" \
--tools read,grep,glob,bash \
--max-turns 8 \
--allow 'bash:go test *' \
--deny 'bash:rm *'
在 headless 模式下，审批默认自动放行，但这一放行受权限门约束，只有被明确允许的操作才会通过。换句话说，headless 不是"完全裸奔"，而是在事先圈定的边界内自主运行。
这一形态面向的是 CI 流水线、定时任务等无人值守场景，把 Agent 嵌入自动化流程，让它在一个可控的范围内独立完成任务。
三种形态，一个内核三种形态共享同一套工具、同一种双模式设计、同一份上下文。差异只在于"以什么方式交互”，是人盯着看、还是脚本调用、还是完全放手。
这也是"全能"的另一层含义，不只意味着"能做很多事"，还意味着"能在很多场景里用"。从日常交互，到脚本集成，再到无人值守，一个 Agent 贯穿始终，不需要为不同场景准备不同的工具。
小结回到系列开头的那句判断：covo-agent 的全能，落点是"收敛"。三种运行形态，本质上是把"人机交互、机器调用、自动化执行"这三类原本分散的需求，收拢到了同一个工具里。