OpenCode高级用法：斜杠命令、Agent模式与上下文管理实战-北京尧图网络

用了那么久的OpenCode我才发现自己一直把它用成了高级聊天框——问一句答一句改个文件跑个测试看起来挺顺但真碰到跨十几个文件、反复改、还要回头查历史决策的任务明显就使不上劲。问题多半不是模型不行而是你对这套命令体系还不够熟。这篇是OpenCode系列的第二篇不聊安装也不聊底层原理就聊命令和技巧。我会把启动参数、斜杠命令、Agent模式切换、会话管理、项目配置这几个层面挨个拆开配合我在真实项目里反复试出来的操作习惯。适合那些已经把OpenCode跑起来、但总觉得差点意思的同学。看完这篇至少能把对话式的临时用法升级成一套可控、可复用的工作流。1. 启动入口与命令行参数别只会敲opencode1.1 裸启动、命名会话与恢复会话大部分人习惯直接在终端敲opencode进默认会话这个用法本身没问题但不太适合多任务并行。我自己在同时维护一套后端服务和一套数据处理脚本时经常遇到两边上下文完全不同的情况。如果混在同一个会话里AI很容易被上一个任务的思路带偏——明明在处理脚本的bug它忽然给你改起后端接口来。这种串味会浪费大量token。要解决这个问题关键是给每个任务独立的会话。opencode -n是新建会话我更推荐直接带上会话名像这样opencode -n 重构登录模块 opencode -n 修复数据管道超时给会话起名不是仪式感而是为了两天后还能想起来这个会话是干嘛的。OpenCode会把会话按名字索引下次想看进度直接用opencode -r进入恢复模式在列表里挑一个历史会话继续。中途不想退出怎么办按快捷键CtrlO也能呼出会话列表不用离开当前对话。这里有个小细节-r和-n是互斥的别又新建又恢复。我一开始老是把参数写反结果每次都是开一个新的空会话前面的上下文全没了心态直接裂开。1.2 非交互模式与批处理除了交互式终端OpenCode还有一个非常有用的非交互模式运行完就退出适合写脚本和做自动化。我常用的姿势是opencode run 把当前目录下所有未提交的改动按文件名列出来 opencode run 给这个项目的README补一段部署说明这个模式在写shell脚本时特别香可以把OpenCode当成一个智能命令工具嵌进你的自动化流程里。比如我有个CI脚本会在每次发版前让OpenCode帮我审查一遍变更文件里有没有写死的密钥几行代码就能接进去。但是要注意非交互模式的token消耗并不低不要真拿它当grep或者jq用。我试过用opencode run 找出所有大于1MB的文件虽然能跑但回复速度比直接用系统命令慢得多成本也高得多。做简单的事情还是先想清楚这个需求是不是真的需要AI介入。1.3 环境变量与模型选择的入口不同项目的模型需求不一样有的追求便宜有的追求代码生成质量。OpenCode读取模型密钥的方式比较统一配置好之后不需要每次手动指定。但如果你手里同时有好几个模型服务商的账号可以用环境变量在项目维度锁定当前会话用哪个OPENCODE_MODEL某个轻量模型 opencode -n 快速修改 OPENCODE_MODEL某个重型模型 opencode -n 大规模重构我个人的习惯是在项目根目录放一个.env文件把当前项目该用的模型、温度参数、工具权限都写清楚。这样换项目、换机器都不用重新记配置团队新成员clone完代码也知道默认用哪套模型。启动参数这块核心思路就一句话别让OpenCode替你默认一切主动指定会话和模型。后面所有的高级用法都建立在这个基础上。2. 对话窗口里的斜杠命令真正高频的其实就几个2.1 /help与/init的分工进入OpenCode的对话窗口第一件事是搞清楚当前环境。很多人遇到问题就到处查文档其实工具自带的斜杠命令体系已经覆盖了大多数场景。先记住两个最基本的/help和/init。/help展示的是当前支持的全部命令和快捷键。注意它显示的是当前会话可用的命令如果你切到了某个受限Agent命令列表会短一截。所以遇到命令怎么不见了的情况先看是不是Agent限制了你。/init则是给当前项目生成一份AGENTS.md之类的项目说明文件里面记录了代码风格、目录结构、常用命令等上下文。这个命令非常容易被忽略但它是长会话不跑偏的秘密武器。我在接手一个不熟悉的旧项目时第一件事就是/init让AI把项目背景先梳理一遍后面的对话质量会明显高一个档次。/init生成的说明不是一次性保障。我建议每当项目结构有大变动比如新加了模块、换了构建工具就重新跑一次/init让AI的项目记忆保持新鲜。2.2 /models与/agents切换模型和角色的正确姿势对话中想换模型很多人以为要退出重开其实直接在输入框里输入/models就行。它会弹出当前可用的模型列表光标选一下回车确认。整个切换不会清空上下文非常顺滑。我实测下来有一个经验同一段对话里尽量不要反复横跳不同厂商的模型。因为不同模型的工具调用约定、回复风格差异很大AI前一眼看到的是另一种模型的输出格式后面切换过来容易产生判断偏差。如果确实想对比模型效果建议开两个独立会话输入相同的问题再对比结果。/agents则负责切换扮演的角色。OpenCode内置了两种基础Agent一种偏规划一种偏执行详见下一节。你还可以在配置文件里自定义Agent比如数据库优化工程师、React组件审查员。切换Agent之后命令、权限、甚至语气都会跟着变。有人会问直接在对话里说你是一个数据库专家不行吗效果当然有一点但远不如自定义Agent稳定。因为Agent可以挂载独立的指令、独立的白名单路径、独立的可用工具这是口头提示没法比的。2.3 /compact的时机与代价长对话最怕的是上下文爆掉。OpenCode有一个/compact命令作用是把前面的对话历史压缩成摘要释放token空间。压缩之后AI还能记住关键结论但记不住每一句原话。关于/compact的时机我的经验是当你发现自己开始重复解释同一个需求的时候就该压缩了。比如你第三次说记住接口返回的是JSON不是XMLAI还是犯同样的错说明上下文里噪声太多有效指令被淹没了。这时候执行一次/compact再把关键约束重新强调一遍效果立竿见影。但要注意压缩是有代价的。如果对话里有非常具体的输出格式、代码片段压缩会把细节丢掉。所以我通常在压缩之前先把当前关键结论手动记到项目笔记文件里压缩完了再贴回去。这一步看着多余实则是长项目的救命稻草。2.4 /config的小技巧/config命令可以让你在对话中查看和修改当前会话的配置比如温度参数、输出偏好、是否允许读写文件等。这个命令适合微调不适合大改。我自己常用它做一件事临时关闭AI的代码执行权限。有时候我只是想让AI先给个设计方案不希望它直接动手改文件或跑命令。这时在/config里把权限收紧等方案确认了再放开。这个习惯能避免AI自作主张改了一堆无关文件。3. Agent模式Plan与Act的分工逻辑3.1 两种模式本质上差在哪OpenCode最值得花时间理解的设计就是Agent模式。基础用法里不存在真正的自动驾驶但通过Plan和Act两种模式的配合你可以让AI按照你的节奏工作。Plan模式负责想。它只读代码、读文档、分析路径最后输出一份改动方案。它不会真的修改任何文件也不会执行命令所以非常安全。Act模式负责做。它拥有读写权限会新建文件、修改代码、跑测试把方案落地。打个比方Plan模式是设计师出图纸Act模式是施工队按图纸施工。你见过哪个靠谱的项目是施工队边想边盖的所以对于复杂任务不要直接切Act模式一顿猛干先切Plan模式把方案聊清楚。3.2 复杂任务先Plan再Act的实际操作我处理一个跨模块重构任务时标准流程是先在Plan模式下发出目标描述比如把订单模块的数据库访问层从原生SQL迁移到查询构建器然后盯着它分析。它会读出相关文件指出哪些地方依赖旧接口哪些测试会受影响。中间我会不断提出疑问xx函数还有其他调用方吗这个兼容层还要不要保留反复几轮直到方案完善。方案确认后再切到Act模式让它按方案去改。执行过程中我依然盯着输出每改完一个文件如果AI没有自动验证我会手动让它跑一遍相关测试。整个过程里AI始终是在执行我的计划而不是自己发明计划。这里有一个重要的操作纪律Plan阶段生成的方案最好让它写进一个文件比如refactor-plan.md。这样即使会话丢失、压缩过上下文方案还在。3.3 模式切换的快捷方式与常见误区模式切换不用退出对话。在输入框里敲/就能看到切换选项也可以用快捷键直接切。切换之后当前对话的上下文会保留但权限边界立刻变化——这就是为什么Plan模式的安全是结构性的不是靠AI自觉。新手常见的误区是开着Act模式让它自由发挥一回头发现它改了十几个文件连带把某个无关的工具脚本也重构了。这不是AI脑子坏了而是你给了它过大的权限。记住一条铁律Act模式只在你已经清楚知道要做什么的时候才打开。探索性、模糊性的问题永远留在Plan模式里。4. 上下文管理让长会话不跑偏4.1 token消耗的直观感受很多人对上下文长度没概念等模型开始失忆才反应过来。OpenCode的上下文是有限窗口对话越长前面的信息被挤得越厉害。我自己测试过一个中等复杂度的重构任务如果从头到尾不压缩、不整理上下文大概聊到二三十轮之后AI就会开始忘记一开始定的接口命名规范。这个阶段有一个非常典型的症状它给你新写的函数起名跟之前完全不在一个体系里。比如前面都叫get_user_profile后面突然冒出fetchProfile。这种失忆不是模型变笨了而是前面那些关键信息被海量的中间过程挤出了有效窗口。4.2 compact的实际代价与补救/compact我之前讲过是压缩历史的工具但它也有自己的代价。压缩是一个摘要生成过程偏向保留结论性信息丢细节。这意味着如果你在第一轮让AI生成了一个完整的数据表结构之后在它基础上改了三次字段名压缩之后很可能只剩有一个用户表这种粒度具体字段名就没了。补救办法是手动锚点。我会在对话中用一个固定格式维护一个需求锚点比如锚点本次项目固定约束 - 接口统一返回 { code, data, message } - 数据库表名一律用下划线分隔 - 日志必须包含 request_id每隔一段时间或者压缩之后重新把这段锚点发给AI。它就知道这些是不能丢的硬性约定。这个土办法比任何自动压缩都可靠。4.3 保持上下文卫生的小习惯上下文卫生不是一次性操作而是一套日常习惯无关话题立刻切会话。不要在一个会话里聊完登录模块又去聊日志组件即使你觉得它们有一点关联。分开会话每个会话的主题单一、干净AI的专注度会高很多。收到长回复后先要求总结。如果AI为了改一个bug输出了大段分析你可以让它把那段的结论压缩成三行要点。这样既保留了关键信息又清掉了过程性的废话。定期用/init刷新项目认识。当项目文件发生结构性变化后做一次/init相当于给AI重新画一张地图它能更准确地定位问题。上下文卫生做得好不好直接决定一个会话能不能用到寿终正寝而不是聊到一半就废掉重开。这套习惯我用了几个月最大的感受就是长会话不再是一件令人焦虑的事。5. 项目配置与自定义Agent把工具调教成自己的形状5.1 配置文件的基本结构OpenCode支持项目级的配置文件我习惯放在项目根目录随代码一起提交到仓库。这样全团队统一配置新成员加入也能立刻继承同样的行为标准。配置里最常见的字段包括模型相关默认模型、温度、最大输出token权限相关哪些目录允许AI读写哪些命令允许执行Agent相关注册自定义Agent并绑定各自的系统提示词工具相关启用的外部MCP工具列表之前有朋友说OpenCode在A项目里表现好、在B项目里表现差我过去一看B项目的配置文件几乎是空的AI既不知道代码风格也没有权限约束全靠自由发挥。配置一个项目和一个初始化项目工作量就差一行命令但效果天差地别。5.2 自定义Agent的写法与实战案例自定义Agent是让你的OpenCode真正贴合团队工作流的东西。你可以在配置里声明一个Agent给它指定一段详细的系统提示词描述它的职责边界、输出风格、禁忌事项。举个例子我写过一个代码审查员Agent它的提示词大概是这样的只读模式禁止修改任何文件审查范围仅限本次改动涉及的函数优先关注安全问题、空指针隐患、明显的性能问题输出格式固定为问题等级、文件定位、建议修改方式实际用下来它比我在对话里口头说帮我看看这段代码有没有问题要专业得多。因为你每次创建这个Agent的会话它的行为都是可预期、可复用的不会因为那天AI心情好就多输出几百行废话。自定义Agent还能和权限绑定。比如你可以把数据库诊断Agent的路径白名单只指向数据库脚本目录这样它就算被误导也动不了业务代码。权限和角色一起绑定才是真正的安全设计。5.3 MCP扩展工具的配置MCP是OpenCode扩展能力的主要方式。通过MCP你可以给AI接上各种外部工具比如查数据库、调接口、操作文件系统。配置方式也很简单在配置文件里声明各个MCP服务器的地址和参数就行。我接入过三类比较有用的MCP工具数据库只读查询工具AI可以直接执行SQL查询来验证自己的假设而不是靠猜HTTP API调试工具让AI在分析接口问题时可以发起真实请求看响应本地文件索引工具让AI能更快地跨越多个目录定位相关代码配置MCP有一个提醒每接入一个工具都要认真想想它的权限边界。AI虽然智能但工具的权限是真实的。一个能执行任意SQL的MCP工具如果配置在共享会话里隐患很大。我通常只给特定Agent挂MCP并且尽量让MCP走只读或沙箱模式。6. 我踩过的坑和沉淀下来的操作纪律6.1 上下文污染的教训最开始我习惯在一个会话里连续处理好几个小任务表面上看起来效率不错。直到有一次我在重构结算逻辑的会话里顺手让AI改了一个日志工具的日期格式。改完之后没觉得有什么问题然后继续聊结算逻辑。半小时后诡异的事情发生了AI在生成新的结算代码时开始主动把日期处理方式改成它刚在日志工具里用过的那套格式还自作主张地给所有接口加上了新的日期字段。我没有要求过这个改动它却以为这是我们项目的新约定。这就是典型的上下文污染一个会话里混入了两个不相干的任务AI无法区分哪条信息属于哪个任务。从那以后我严格执行一任务一会话的纪律。哪怕只是顺手的小修改也先记录到当前任务清单再决定要不要新开会话。省下的token比一次聊完多得多。6.2 路径限制与权限边界的教训另一个坑发生在配置文件里。我一开始图省事权限目录写得很大比如直接把整个家目录设为可读。有一次AI在Plan模式分析问题聊天记录里看不到任何异常但当我切到Act模式执行时它开始扫描很多与任务无关的文件夹读取了不该读的项目配置。虽然最终没有造成损坏但这件事给我提了个醒权限要给得刚刚好。我会根据每个项目的实际需求把读写范围收窄到src、tests、docs等明确目录。遇到需要额外访问的情况再单独补充配置。更稳妥的做法是把默认读写改成默认只读按需写。AI需要改文件时它会在对话里请求权限我确认之后才放开。这个过程看起来多了一步但换来的是对整个改动范围的绝对掌控。6.3 我的一套日常干活流程沉淀到最后我日常用OpenCode干活基本是这个套路先判断任务类型。如果是一次性小问题比如这段函数哪里错了直接用默认会话问得到答案就退出。如果是跨模块的中型任务我会为它专门开一个会话先/init建立项目背景然后切Plan模式让AI梳理方案方案确认后写成文档存到项目里再切Act模式执行。执行过程中我会保持小步推进不让AI一次性改完所有东西。每完成一个步骤我会要求它总结做了什么、影响哪些文件、有没有跑测试。这样即使中途发现问题也能精确定位到是哪一步造成的。最后无论任务成功与否我都会把关键结论追加到项目笔记里。下次再碰到类似问题翻笔记比翻聊天记录快得多。这套流程并不复杂但每一步都在回答同一件事是你在让AI干活不是AI在替你决定干什么。命令和快捷键只是表层真正的效率来自使用者的纪律感。当你熟练到不用想该用哪个命令的时候OpenCode就不再是一个懂代码的聊天框而是你实际工作中的杠杆。

OpenCode高级用法：斜杠命令、Agent模式与上下文管理实战

相关推荐

CS229机器学习课程资料包：讲义、作业与讲解的完整使用指南

微网系统碳交易优化模型设计与Matlab实现

UGC3.0触发器与脚本交互：从可视化规则到可编程事件源的玩法设计实践

更多资讯

SSM网络硬盘管理系统：从数据库设计到部署的全流程实战解析

ICPC算法题解析：序列重排与逆序数计算

SAP-HR薪酬管理实战：主数据、工资项与核算流程全解析

macOS高性能计时：mach_absolute_time原理与实战

美团清华产品课PDF：从产品思维到需求分析SOP的实战应用

OpenJDK 21在Windows x64下的安装配置与常见坑解析

今日更新

小波包能量谱原理与MATLAB实现：从频带分解到故障特征提取

基于LSTM的网易云音乐评论情感分析：数据清洗与模型调优实战

Alpha-Beta剪枝与极大极小值算法：博弈树搜索原理与实战优化

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？