Open Interpreter 的 OpenCode Harness一份系统提示词如何驱动一个完整的编码智能体【免费下载链接】openinterpreterA coding agent for open models like Kimi K3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter在 Open Interpretercodex-rs的多智能体运行框架harness中opencode_system_prompt.md是 OpenCode 这个 harness 的核心行为契约它定义了智能体的角色身份、语气风格、任务执行流程、工具使用策略与代码引用规范。读完本文你既能逐条理解这份提示词的设计意图也能从源码层面看清它如何被编译进二进制、与运行时环境信息拼接、与十件工具集配套并最终以标准 chat-completions 请求发给模型。提示词文件在代码中的位置与加载方式该提示词不是一个普通的文档而是通过 Rust 的include_str!宏在编译期嵌入二进制源码的常量。在 opencode.rs 中可以看到const OPENCODE_SYSTEM_PROMPT_PREFIX: str include_str!(opencode_system_prompt.md);同目录下还有两份配套提示词opencode_search_agent_prompt.md搜索子智能体search agent的完整指令替代主提示词使用opencode_title_prompt.md会话标题生成的专用提示词。harness/模块还包含 claude-code、kimi-cli、qwen-code、swe-agent、minimal 等多个 harness每个 harness 都是提示词 工具集 请求整形逻辑的组合。OpenCode 是其中完全走 OpenAI chat-completions 风格system/user/assistant/tool 角色、JSON function calling的一条路线。提示词全文逐节解读角色定位与 URL 安全边界提示词的第一句确立了身份You are opencode, an interactive CLI tool that helps users with software engineering tasks.——一个帮助用户完成软件工程任务的交互式 CLI 工具。紧接着是一条硬性安全约束除非确信该 URL 是用于辅助编程的否则永远不得生成或猜测 URL可以安全使用的是用户消息或本地文件中已出现的 URL。这条规则直接约束了webfetch工具的调用行为——智能体只能抓取用户显式给出的或项目中存在的地址而不是自行编造来源。帮助与反馈通道提示词要求当用户请求帮助或反馈时告知用户/help命令以及到 opencode 的官方 issue 跟踪渠道报告问题当用户直接询问 opencode 自身能力can opencode do...时应先用WebFetch工具从官方文档站获取信息再作答。这体现了自我描述也要有证据来源的设计思路——关于产品自身的事实性回答不靠模型记忆而是现场拉取文档。语气与风格为终端而生的极简主义这一节是整份提示词篇幅最大的部分核心思想是输出会显示在命令行界面上因此简洁直接输出用 GitHub-flavored markdown按 CommonMark 规范在等宽字体下渲染文本与工具分离工具调用之外的所有文本都会显示给用户因此禁止用 Bash 命令或代码注释来说话只通过正文与用户沟通拒绝说教当无法满足请求时不解释原因只给替代方案且回应控制在 1~2 句默认不用 emoji除非用户明确要求最小化 token 输出能用 1~3 句话回答就不展开。提示词甚至给出了强制性的量化标准——正文必须少于 4 行工具调用与代码生成除外并附了六个正反例示范例如用户问 what is 22?助手只答4用户问 is 11 a prime number?助手只答Yes用户问列目录的命令助手只答ls用户问src/下哪个文件实现了foo助手先并行运行ls与文档搜索最终只输出src/foo.cwrite tests for new feature 的正确做法是用搜索工具找到同类测试、在一个消息中并发读取多个相关文件、再用编辑工具写入新测试。这组示例本质上是在教模型终端交互的默认熵是多少——答案是一词一句而不是聊天助手的完整段落。主动性Proactiveness的三条平衡线提示词允许主动但划定了三条边界被要求时做对的事包括必要的后续动作不做出让用户意外的动作——用户问怎么做时先回答问题而不是立刻动手改文件修改文件后直接停止不主动附上我做了什么的代码解释总结。遵循既有约定改文件前先理解文件的代码约定展开为四条细则模仿现有代码风格绝不假设某个库可用——即使用户没写package.json/Cargo.toml也要去查创建新组件前先读同类组件编辑代码前先读周边上下文尤其是 import 区。最后一条是安全红线绝不引入暴露或记录密钥的代码绝不把密钥提交进仓库。代码风格默认零注释IMPORTANT: DO NOT ADDANYCOMMENTS unless asked——除非用户要求否则不添加任何注释。这与简洁主题一脉相承注释被视为噪音除非用户显式索要。任务执行流程针对软件工程任务修 bug、加功能、重构、解释代码提示词给出推荐步骤充分使用搜索工具理解代码库鼓励并行与串行结合用所有可用工具实现方案验证能用测试验证就验证且绝不假设特定的测试框架或脚本——要查 README 或搜代码库确定测试方式完成后必须运行 lint 与类型检查命令如npm run lint、npm run typecheck、ruff如果找不到命令问用户要并主动建议把命令写进AGENTS.md以便下次已知。紧随其后的是提交红线除非用户明确要求绝不执行 git commit。原文用了VERY IMPORTANT强调——擅自提交会让用户觉得智能体过于主动。此外还有一条协议层约定工具结果和用户消息中可能包含system-reminder标签这些是系统注入的有用信息不属于用户输入或工具结果的一部分——智能体应把它当作环境提示而非用户指令。工具使用策略与代码引用格式文件搜索优先用 Task 工具子智能体以减少主上下文消耗多个独立请求应批量并发单条消息里放多个 bash 工具调用并行执行例如同时跑git status和git diff。提示词以# Code References一节收尾引用具体函数或代码时必须使用file_path:line_number格式如src/services/process.ts:712方便用户直接跳转。这与仓库内其他 harness 的约定一致是终端智能体可操作性的关键细节。源码级拼装环境块与技能清单提示词文件只是前缀。build_system_prompt 在运行时把它包装成完整的 system 消息let prompt_prefix if is_search_agent_prompt(prompt) { OPENCODE_SEARCH_AGENT_BASE_INSTRUCTIONS.trim_end() } else { OPENCODE_SYSTEM_PROMPT_PREFIX.trim_end() };即如果本轮是搜索子智能体则整段替换为 opencode_search_agent_prompt.mdYou are a file search specialist...只允许只读探索、最终返回绝对路径否则使用主提示词。随后拼接的模板包含一段env环境块源码见 opencode.rs L126-L132env Working directory: {cwd} Workspace root folder: {workspace_root} Is directory a git repo: yes Platform: {platform} Todays date: {today} /env其中两个细节值得注意平台归一化opencode_platform 把 macOS 上报为darwin而非macosLinux 下workspace root在 cwd 位于顶层时特殊处理为/见 opencode_workspace_root技能清单注入主提示词后还会追加一段available_skills块声明内置技能customize-opencode仅在用户编辑 opencode 自身配置时触发并说明用 skill 工具加载技能。搜索子智能体则不带技能块。十件工具集及其裁剪变体与这份提示词配套的工具由 build_tools 定义共 10 个全部采用 JSON Schemadraft 2020-12描述参数工具关键参数提示词中的对应约定bashcommand、timeout毫秒、workdir、description用workdir替代cd输出超 2000 行/51200 字节自动落盘editfilePath、oldString、newString、replaceAll必须先 Read 过才能 EditoldString不唯一会报错globpattern、path按名称找文件结果按修改时间排序greppattern正则、path、include内容搜索用正则不用 shell 的 grepreadfilePath、offset1 起始、limit默认 2000 行行号前缀格式line: content行超 2000 字符截断skillname加载available_skills中列出的技能taskdescription、prompt、subagent_type、task_id对应提示词文件搜索优先用 Task 工具省上下文todowritetodoscontent/status/priority多步任务维护结构化待办同一时刻只能一个in_progresswebfetchurl、formatmarkdown/text/html、timeout即提示词中提到的 WebFetchHTTP 自动升级 HTTPSwritecontent、filePath必须绝对路径覆盖写不主动创建 README注意每个工具的描述本身就是第二层提示词。例如bash的描述动态注入当前平台、shellLinux 固定bash其他平台读$SHELL与临时目录并完整复述了 Git 规范只在明确要求时才 commit/push/建 PR、提交前检查git status/diff/log、失败后新建提交而非 amend 失败提交等——与系统提示词NEVER commit unless asked形成呼应。工具集还有两个裁剪变体build_search_agent_tools搜索子智能体只保留bash、glob、grep、read、webfetch五件只读/探查类工具配合搜索提示词不得创建文件、不得修改系统状态build_task_agent_tools任务子智能体去掉task与todowrite防止子智能体再嵌套派发子智能体或越权维护主会话待办。请求整形参数、标题生成与消息映射build_request 将一切组装为 chat-completions 请求体关键参数max_tokens: 32000常量 OPENCODE_MAX_TOKENSstream: true且stream_options.include_usage: true便于统计 token 用量tool_choice: autotemperature: 1但任务子智能体例外见 L93-L95——从源码结构看这是给子智能体更低的采样自由度消息列表由 build_messages 生成其中包含若干针对 opencode 线协议的适配用户消息内容经 quote_prompt_for_opencode 做 JSON 字符串化并规范化换行符normalize_prompt_newlines专门处理\n、printf SHELL_OK\n等易被模型破坏的形态developer 角色降级为 useropencode 线协议没有 developer 角色源码注释明确指出workspace harness 的指令角色规则要求 developer 消息包括skills_instructions块映射为 user 内容而不是丢弃见 L214-L234配套测试opencode_request_maps_developer_skills_block_to_user_message验证了这一点本地 shell 调用统一折叠为bash工具调用工具调用与输出成对挂接到 assistant 消息的tool_calls与tool角色消息上。标题生成是 OpenCode harness 独有的额外请求should_generate_title 在首轮对话仅 user/developer 消息且本进程尚未发过标题请求时用原子布尔量保证只触发一次build_title_request 以 opencode_title_prompt.md 为 system 提示词要求单行、不超过 50 字符、与用户消息同语言、不含工具名、保留技术术语与文件名与首轮用户消息一起构成一个独立的流式请求。这条链路在 request.rs 的ChatHarnessRoute::OpenCode分支中被组装进ChatHarnessRequest的title_request字段。路由约束与启用方式OpenCode harness 在路由层有明确约束。从 routing.rs 看wire_api chatharness opencode→ 走ChatHarness(ChatHarnessRoute::OpenCode)原生整形路线L80-L82配套测试opencode_chat_wire_uses_harness_native_chat_route验证此行为wire_api messages会被显式拒绝错误信息为 wire_api messages is not supported by harness opencodeL121-L123——即 OpenCode 只能跑在 chat-completions 线协议上这一点适用于所有使用harness opencode配置的部署。配置名到枚举的映射在 harness.rs 中完成Some(opencode) Self::OpenCode。还有一个容易忽略的事实guidance.rs 中Open Interpreter 的附加编码任务指导Open Interpreter Guidance只注入给 kimi-cliOpenCode harness 不在注入列表里。也就是说OpenCode 的行为完全由它自己的提示词与工具描述决定不受 Open Interpreter 全局指导块的改写——这也保证了这份提示词的设计意图原样抵达模型。小结opencode_system_prompt.md表面上是一份少说话、多干活、别乱提交的行为守则但在 Open Interpreter 的 codex-rs 中它是 OpenCode harness 三角结构提示词、工具集、请求整形的顶端编译期嵌入、运行时拼接环境与技能清单、配合十件 JSON Schema 工具与 32000 token 的流式请求模板并受仅 chat 线协议的路由约束。理解这份提示词的每一节——从少于 4 行的输出纪律到file_path:line_number引用格式——都能在你自己设计 CLI 编码智能体时直接复用它是提示词即产品行为规格的一个完整范本。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Open Interpreter 的 OpenCode Harness：一份系统提示词如何驱动一个完整的编码智能体
Open Interpreter 的 OpenCode Harness一份系统提示词如何驱动一个完整的编码智能体【免费下载链接】openinterpreterA coding agent for open models like Kimi K3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter在 Open Interpretercodex-rs的多智能体运行框架harness中opencode_system_prompt.md是 OpenCode 这个 harness 的核心行为契约它定义了智能体的角色身份、语气风格、任务执行流程、工具使用策略与代码引用规范。读完本文你既能逐条理解这份提示词的设计意图也能从源码层面看清它如何被编译进二进制、与运行时环境信息拼接、与十件工具集配套并最终以标准 chat-completions 请求发给模型。提示词文件在代码中的位置与加载方式该提示词不是一个普通的文档而是通过 Rust 的include_str!宏在编译期嵌入二进制源码的常量。在 opencode.rs 中可以看到const OPENCODE_SYSTEM_PROMPT_PREFIX: str include_str!(opencode_system_prompt.md);同目录下还有两份配套提示词opencode_search_agent_prompt.md搜索子智能体search agent的完整指令替代主提示词使用opencode_title_prompt.md会话标题生成的专用提示词。harness/模块还包含 claude-code、kimi-cli、qwen-code、swe-agent、minimal 等多个 harness每个 harness 都是提示词 工具集 请求整形逻辑的组合。OpenCode 是其中完全走 OpenAI chat-completions 风格system/user/assistant/tool 角色、JSON function calling的一条路线。提示词全文逐节解读角色定位与 URL 安全边界提示词的第一句确立了身份You are opencode, an interactive CLI tool that helps users with software engineering tasks.——一个帮助用户完成软件工程任务的交互式 CLI 工具。紧接着是一条硬性安全约束除非确信该 URL 是用于辅助编程的否则永远不得生成或猜测 URL可以安全使用的是用户消息或本地文件中已出现的 URL。这条规则直接约束了webfetch工具的调用行为——智能体只能抓取用户显式给出的或项目中存在的地址而不是自行编造来源。帮助与反馈通道提示词要求当用户请求帮助或反馈时告知用户/help命令以及到 opencode 的官方 issue 跟踪渠道报告问题当用户直接询问 opencode 自身能力can opencode do...时应先用WebFetch工具从官方文档站获取信息再作答。这体现了自我描述也要有证据来源的设计思路——关于产品自身的事实性回答不靠模型记忆而是现场拉取文档。语气与风格为终端而生的极简主义这一节是整份提示词篇幅最大的部分核心思想是输出会显示在命令行界面上因此简洁直接输出用 GitHub-flavored markdown按 CommonMark 规范在等宽字体下渲染文本与工具分离工具调用之外的所有文本都会显示给用户因此禁止用 Bash 命令或代码注释来说话只通过正文与用户沟通拒绝说教当无法满足请求时不解释原因只给替代方案且回应控制在 1~2 句默认不用 emoji除非用户明确要求最小化 token 输出能用 1~3 句话回答就不展开。提示词甚至给出了强制性的量化标准——正文必须少于 4 行工具调用与代码生成除外并附了六个正反例示范例如用户问 what is 22?助手只答4用户问 is 11 a prime number?助手只答Yes用户问列目录的命令助手只答ls用户问src/下哪个文件实现了foo助手先并行运行ls与文档搜索最终只输出src/foo.cwrite tests for new feature 的正确做法是用搜索工具找到同类测试、在一个消息中并发读取多个相关文件、再用编辑工具写入新测试。这组示例本质上是在教模型终端交互的默认熵是多少——答案是一词一句而不是聊天助手的完整段落。主动性Proactiveness的三条平衡线提示词允许主动但划定了三条边界被要求时做对的事包括必要的后续动作不做出让用户意外的动作——用户问怎么做时先回答问题而不是立刻动手改文件修改文件后直接停止不主动附上我做了什么的代码解释总结。遵循既有约定改文件前先理解文件的代码约定展开为四条细则模仿现有代码风格绝不假设某个库可用——即使用户没写package.json/Cargo.toml也要去查创建新组件前先读同类组件编辑代码前先读周边上下文尤其是 import 区。最后一条是安全红线绝不引入暴露或记录密钥的代码绝不把密钥提交进仓库。代码风格默认零注释IMPORTANT: DO NOT ADDANYCOMMENTS unless asked——除非用户要求否则不添加任何注释。这与简洁主题一脉相承注释被视为噪音除非用户显式索要。任务执行流程针对软件工程任务修 bug、加功能、重构、解释代码提示词给出推荐步骤充分使用搜索工具理解代码库鼓励并行与串行结合用所有可用工具实现方案验证能用测试验证就验证且绝不假设特定的测试框架或脚本——要查 README 或搜代码库确定测试方式完成后必须运行 lint 与类型检查命令如npm run lint、npm run typecheck、ruff如果找不到命令问用户要并主动建议把命令写进AGENTS.md以便下次已知。紧随其后的是提交红线除非用户明确要求绝不执行 git commit。原文用了VERY IMPORTANT强调——擅自提交会让用户觉得智能体过于主动。此外还有一条协议层约定工具结果和用户消息中可能包含system-reminder标签这些是系统注入的有用信息不属于用户输入或工具结果的一部分——智能体应把它当作环境提示而非用户指令。工具使用策略与代码引用格式文件搜索优先用 Task 工具子智能体以减少主上下文消耗多个独立请求应批量并发单条消息里放多个 bash 工具调用并行执行例如同时跑git status和git diff。提示词以# Code References一节收尾引用具体函数或代码时必须使用file_path:line_number格式如src/services/process.ts:712方便用户直接跳转。这与仓库内其他 harness 的约定一致是终端智能体可操作性的关键细节。源码级拼装环境块与技能清单提示词文件只是前缀。build_system_prompt 在运行时把它包装成完整的 system 消息let prompt_prefix if is_search_agent_prompt(prompt) { OPENCODE_SEARCH_AGENT_BASE_INSTRUCTIONS.trim_end() } else { OPENCODE_SYSTEM_PROMPT_PREFIX.trim_end() };即如果本轮是搜索子智能体则整段替换为 opencode_search_agent_prompt.mdYou are a file search specialist...只允许只读探索、最终返回绝对路径否则使用主提示词。随后拼接的模板包含一段env环境块源码见 opencode.rs L126-L132env Working directory: {cwd} Workspace root folder: {workspace_root} Is directory a git repo: yes Platform: {platform} Todays date: {today} /env其中两个细节值得注意平台归一化opencode_platform 把 macOS 上报为darwin而非macosLinux 下workspace root在 cwd 位于顶层时特殊处理为/见 opencode_workspace_root技能清单注入主提示词后还会追加一段available_skills块声明内置技能customize-opencode仅在用户编辑 opencode 自身配置时触发并说明用 skill 工具加载技能。搜索子智能体则不带技能块。十件工具集及其裁剪变体与这份提示词配套的工具由 build_tools 定义共 10 个全部采用 JSON Schemadraft 2020-12描述参数工具关键参数提示词中的对应约定bashcommand、timeout毫秒、workdir、description用workdir替代cd输出超 2000 行/51200 字节自动落盘editfilePath、oldString、newString、replaceAll必须先 Read 过才能 EditoldString不唯一会报错globpattern、path按名称找文件结果按修改时间排序greppattern正则、path、include内容搜索用正则不用 shell 的 grepreadfilePath、offset1 起始、limit默认 2000 行行号前缀格式line: content行超 2000 字符截断skillname加载available_skills中列出的技能taskdescription、prompt、subagent_type、task_id对应提示词文件搜索优先用 Task 工具省上下文todowritetodoscontent/status/priority多步任务维护结构化待办同一时刻只能一个in_progresswebfetchurl、formatmarkdown/text/html、timeout即提示词中提到的 WebFetchHTTP 自动升级 HTTPSwritecontent、filePath必须绝对路径覆盖写不主动创建 README注意每个工具的描述本身就是第二层提示词。例如bash的描述动态注入当前平台、shellLinux 固定bash其他平台读$SHELL与临时目录并完整复述了 Git 规范只在明确要求时才 commit/push/建 PR、提交前检查git status/diff/log、失败后新建提交而非 amend 失败提交等——与系统提示词NEVER commit unless asked形成呼应。工具集还有两个裁剪变体build_search_agent_tools搜索子智能体只保留bash、glob、grep、read、webfetch五件只读/探查类工具配合搜索提示词不得创建文件、不得修改系统状态build_task_agent_tools任务子智能体去掉task与todowrite防止子智能体再嵌套派发子智能体或越权维护主会话待办。请求整形参数、标题生成与消息映射build_request 将一切组装为 chat-completions 请求体关键参数max_tokens: 32000常量 OPENCODE_MAX_TOKENSstream: true且stream_options.include_usage: true便于统计 token 用量tool_choice: autotemperature: 1但任务子智能体例外见 L93-L95——从源码结构看这是给子智能体更低的采样自由度消息列表由 build_messages 生成其中包含若干针对 opencode 线协议的适配用户消息内容经 quote_prompt_for_opencode 做 JSON 字符串化并规范化换行符normalize_prompt_newlines专门处理\n、printf SHELL_OK\n等易被模型破坏的形态developer 角色降级为 useropencode 线协议没有 developer 角色源码注释明确指出workspace harness 的指令角色规则要求 developer 消息包括skills_instructions块映射为 user 内容而不是丢弃见 L214-L234配套测试opencode_request_maps_developer_skills_block_to_user_message验证了这一点本地 shell 调用统一折叠为bash工具调用工具调用与输出成对挂接到 assistant 消息的tool_calls与tool角色消息上。标题生成是 OpenCode harness 独有的额外请求should_generate_title 在首轮对话仅 user/developer 消息且本进程尚未发过标题请求时用原子布尔量保证只触发一次build_title_request 以 opencode_title_prompt.md 为 system 提示词要求单行、不超过 50 字符、与用户消息同语言、不含工具名、保留技术术语与文件名与首轮用户消息一起构成一个独立的流式请求。这条链路在 request.rs 的ChatHarnessRoute::OpenCode分支中被组装进ChatHarnessRequest的title_request字段。路由约束与启用方式OpenCode harness 在路由层有明确约束。从 routing.rs 看wire_api chatharness opencode→ 走ChatHarness(ChatHarnessRoute::OpenCode)原生整形路线L80-L82配套测试opencode_chat_wire_uses_harness_native_chat_route验证此行为wire_api messages会被显式拒绝错误信息为 wire_api messages is not supported by harness opencodeL121-L123——即 OpenCode 只能跑在 chat-completions 线协议上这一点适用于所有使用harness opencode配置的部署。配置名到枚举的映射在 harness.rs 中完成Some(opencode) Self::OpenCode。还有一个容易忽略的事实guidance.rs 中Open Interpreter 的附加编码任务指导Open Interpreter Guidance只注入给 kimi-cliOpenCode harness 不在注入列表里。也就是说OpenCode 的行为完全由它自己的提示词与工具描述决定不受 Open Interpreter 全局指导块的改写——这也保证了这份提示词的设计意图原样抵达模型。小结opencode_system_prompt.md表面上是一份少说话、多干活、别乱提交的行为守则但在 Open Interpreter 的 codex-rs 中它是 OpenCode harness 三角结构提示词、工具集、请求整形的顶端编译期嵌入、运行时拼接环境与技能清单、配合十件 JSON Schema 工具与 32000 token 的流式请求模板并受仅 chat 线协议的路由约束。理解这份提示词的每一节——从少于 4 行的输出纪律到file_path:line_number引用格式——都能在你自己设计 CLI 编码智能体时直接复用它是提示词即产品行为规格的一个完整范本。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考