定位
面向希望拥有一个私有、常驻、真正会动手做事（而不只是聊天）的 AI 助手，并在自己已在用的每个模型与编码 CLI 前放一个统一、可控网关的开发者与小团队。
核心能力
GoWork
01
运行常驻 ReAct 助手：它会思考、调用工具、读取结果，持续推进直到任务完成——或在需要你确认时停下来征询。
02
在本机直接动手：读写文件、执行 shell 命令、联网搜索与抓取网页、生成图片、读取 PDF/Office 文档——全部在受保护的工作区内。
03
把编程委派给运行时：将任务交给 Codex 或 Claude Code，并可流式跟踪、续跑或中断。
04
跨会话记忆：分「你 / 项目 / 会话 / 执行」四层作用域的长期记忆，还能把记忆固化成可复用的技能。
05
定时与自动化：声明式的一次 / 每天 / 每周 / 每月任务，到点提醒你，或直接唤起助手执行。
06
随时随地触达：通过钉钉、飞书、Telegram（微信为实验性接入）触达，并可主动回推文本与图片。
07
安全且本地：默认拒绝的工具策略加审批治理，以及一个带账号池与用量统计的模型网关——凭证与记录都留在 ~/.gowork。
为明确的操作者而设计
AI 优先的开发者编码 Agent 重度用户小团队与工作室自动化与运维搭建者
产品
覆盖的接入面与平台
模型供应商
渠道
助手能力
相关阅读
GoWork — 快速开始
安装 GoWork，接入你的模型与编码 CLI，让常驻助手开始为你做事。
核心概念
GoWork 的工作原理——一个常驻助手，建立在本地模型网关之上，一切都在你自己的机器上运行。
助手能力
GoWork 常驻助手能做什么——执行任务、使用工具、保留记忆、自动定时、委派编码，并通过 IM 触达你。
模型网关
一个本地端点，接管你的模型与编码 CLI——提供账号池、密钥管理、模型映射与用量统计。
渠道
通过 IM 触达 GoWork 助手——钉钉、飞书、Telegram（微信实验性）——并在手机上让任务继续运行。
参考
GoWork 的数据存放位置、本地端口、账号命令与环境变量。
AI 助理和聊天机器人差在哪
AI 助理和聊天机器人最大的差别，不在会不会聊天，而在能否基于上下文持续执行任务、调用工具、回报进度并把结果真正交付出去。本文用 GoWork 的执行链路解释两者为什么不是一类产品。
阅读技能列表为什么要有刷新按钮？外部新增 skill 如何立即被 GoWork 发现
GoWork 技能列表里的刷新按钮不是界面点缀，而是把“等缓存自己过期”变成“我刚改完就立刻重建索引”的确定性操作。本文解释它为什么重要、解决了什么问题，以及遇到新 skill 不显示时该怎么排查。
阅读为什么超时要贯穿到底层执行器
超时如果只停在助理表层，底层命令、子进程和桌面动作仍可能继续跑。本文解释为什么执行型 AI 助理必须把 timeout 一路传到底层执行器，并用优雅停机替代简单粗暴的直接杀掉。
阅读为什么任务状态不能只看会话摘要
任务状态查询不能只盯着 conversation summary。真正可靠的进度判断，要同时看 runtime 状态、recent events、等待原因和最近执行证据。本文解释这几个层次分别回答什么问题。
阅读什么时候该用结构化表单追问，什么时候一句话就够了
解释 GoWork 在执行任务前，什么时候该用结构化 clarification 表单一次性收齐多个明确字段，什么时候只该用一句自然语言追问来澄清意图，避免把简单协作做成过度流程化。
阅读长任务为什么要分轮续跑
解释 GoWork 里的 Assistant continuation rounds 与交接摘要为什么要成对设计：什么时候应该 declare_continuation，交接里必须写什么，为什么它比一句“下轮继续”更能保证长任务不丢进度。
阅读为什么常驻助理需要全局并发闸门
任务并行不等于所有动作都该同时放行。本文解释执行型 AI 助理为什么需要全局并发闸门，来区分真正可并行的工作、必须串行的独占资源，以及何时该排队、改向或只读回答。
阅读哪些只读工具该并行，哪些桌面动作必须串行
只读工具适合并行批量跑，但桌面控制、有副作用的文件改写和有依赖链的动作必须串行。本文用 GoWork 的执行场景解释工具并行度的边界，以及为什么错误的并行会破坏证据链与任务稳定性。
阅读新技能为什么装好了却还看不到？GoWork 的技能发现缓存、刷新与重扫
GoWork 新技能明明已经放到目录里却看不到，通常不是技能坏了，而是技能发现缓存、刷新入口和全局重扫时机共同作用的结果。本文解释缓存 TTL、刷新按钮、junction 限制与正确排查顺序。
阅读桌面被占用时怎么办：resource holders 与自动排队的正确用法
当桌面正被别的任务占用时，GoWork 不该因为资源冲突就取消并行任务。本文解释 resource holders、桌面队列与并发调度怎么配合，以及为什么“排队等待”比抢鼠标或误停任务更可靠。
阅读“任务到哪了”和“停下别做了”不能混着处理
用户问任务进度时，AI 助理应优先做只读状态查询；用户明确说停下时，则应取消正在运行的任务。把这两类消息混为一谈，会直接带来重复执行、错误中断和资源冲突。
阅读为什么工具调用前要先说意图
工具调用前先用一句话说明你看到了什么、准备做什么、接下来怎么推进，能显著提升 AI 助理的可审计性、用户信任和纠偏效率。本文解释这条规则为什么重要，以及该怎么写才不啰嗦。
阅读长任务为什么要定期回报进度心跳
一个执行多步任务的 AI 助理长时间不吭声，用户最容易失去信任。本文解释你定期回报进度心跳的原因、心跳该包含什么、怎么做才不会打扰用户。
阅读“下一步我会去做”为什么不等于任务完成
很多 AI 助理会把“我接下来会继续处理”说成像结果一样，但承诺下一步不等于已经完成执行。本文解释 assistant_done 与 continuation 的边界，以及 GoWork 为什么要求任务做到自然完成点再汇报。
阅读原截图为什么该先 view_image
解释用户要求查看原来截图时，为什么应先用 view_image 回看历史证据，而不是重新截图覆盖现场；适用于 GoWork 的桌面取证、排障与任务回溯。
阅读桌面截图为什么要先转写关键文字：别让图像信息在下一轮上下文里消失
桌面自动化里，截图本身不等于可持续的任务证据。只要下一轮上下文不再携带图像，未转写的关键信息就会丢失。本文解释为什么 GoWork 里的截图应先转成可引用文字，再决定下一步动作。
阅读追问之前先回忆：什么时候该读记忆，什么时候才该向用户补问题
当 AI 助理看起来“信息不够”时，最稳的默认动作并不是立刻追问用户，而是先检查记忆、历史记录和已知线索。本文解释什么时候该先 recall，什么时候才该 clarification。
阅读多步任务为什么不能只在当轮写计划：update_plan 跨轮持久化的价值
多步任务最怕的不是模型不聪明，而是每轮都重新开始理解上下文。本文解释为什么 update_plan 的跨轮持久化，是 GoWork 把长任务从“会聊天”变成“能持续推进”的关键能力。
阅读用户问上次做了什么时，为什么先查运行档案
用户追问上次到底做了什么时，最稳的做法不是重探线上系统，而是先查运行档案。本文解释为什么执行档案比即时重试更可靠，以及 GoWork 如何把这件事做成可复用的协作链。
阅读Runtime 审批、assistant 确认和 auto-approve 到底是什么关系
解释 GoWork 里 runtime 审批、assistant 确认与 auto-approve 的分工：前两者解决“这一步能不能做”，后者解决“常规步骤还要不要每次都问”，三者不是同一层，也不能互相替代。
阅读用户只问“现在到哪了”时，为什么不该重跑任务
用户只是在问任务进度时，最稳的处理方式通常是读取当前 run 的状态摘要与 recent events，而不是重新操作桌面、重开网页或重跑整条任务。本文解释这种边界为什么决定执行型 AI 助理的稳定性。
阅读桌面任务排队不等于串行系统：GoWork 如何同时并行多任务又避免抢鼠标
很多人看到 GoWork 的桌面任务会排队，就以为系统只能一次做一件事。其实真正被串联的只是独占桌面资源；聊天、读写文件、查状态、后台任务仍可并行。本文解释这条边界为什么决定了执行效率与稳定性。
阅读任务委派和本地执行怎么选？GoWork 的边界
任务委派和本地执行不是同一件事。本文解释 GoWork 里什么情况该让 runtime 接手，什么情况应由本地 assistant 直接完成，以及这条边界为什么决定执行效率与结果可信度。
阅读Web 对话里什么时候该用表单追问
解释 GoWork 在 Web 对话里何时应该用结构化 clarification 表单、何时只该问一句自然语言问题，以及为什么把开放问题硬塞进表单反而会让协作更慢。
阅读查提醒时为什么会看到全局结果？
解释 GoWork 里 reminder 列表默认为什么按全局 scope 返回，以及 current conversation 什么时候才是正确范围，避免把“任务查询范围”和“通知目标”混为一谈。
阅读盯着检查和每天提醒不是一回事
解释 GoWork 里 interval 与 daily 的边界：什么时候该持续轮询状态，什么时候该落在固定钟点提醒，避免把“每 N 小时”建错成会漂移或根本盯不住条件的任务。
阅读条件命中后为什么要主动取消定时任务
解释 GoWork 里监控类定时任务为什么在条件达成后要主动 cancel：否则轮询会继续消耗频率、制造重复通知，并把原本“一次性盯到发生为止”的任务变成长期噪音。
阅读AI 助理记错了怎么办
当 AI 助理把偏好、事实或任务对象记错时，真正关键的不是“它有没有记忆”，而是系统有没有召回、证据核对、用户修正与记忆更新机制。本文解释为什么可纠错记忆才适合真实协作。
阅读Agent 架构为什么要把“大脑”和“手”拆开
agent 架构不是把所有能力塞进一个进程里。本文解释为什么“会思考的助理”和“会干活的手”应当拆分，以及这种分工如何提升稳定性、可审计性与执行成功率。
阅读定时任务跑完后怎么回报结果
解释 GoWork 定时任务在执行结束后该如何回报结果：什么时候只发一句摘要，什么时候要写完整运行报告，什么时候应该静默，以及如何设计对用户真正有用的通知文案。
阅读自动同意模式不等于无限权限
解释 GoWork 自动同意模式的真实边界：常规读写和命令可直接执行，但删除数据、对外发布、发消息、提交表单等高影响动作，仍然需要明确授权或本轮预授权。
阅读GoWork 定时任务通知会发到哪里？
GoWork 的定时任务不是只有“到点提醒”这一种结果形态。通知会不会回到当前会话、为什么“我有哪些提醒”默认看的是全局、以及什么时候应该改成静默运行，关键都取决于 notifyTargets、会话范围和任务触发方式。
阅读为什么运维团队需要会记忆的 AI 助理，而不只是机器人
运维团队的 AI 如果只会当场回一句，很快就会在交接、追问、失败续跑和定时跟进里掉链子。要让它真正进入日常协作，关键不是更会聊天，而是具备记忆、任务历史和可回溯执行能力。
阅读定时发布和轮询任务有什么区别
解释定时发布与轮询任务的差别：定时发布用于在明确时间点发内容，轮询任务用于持续检查条件并在命中后执行动作，适合内容运营、自动跟进与状态监控。
阅读让 GoWork 定时跑内容流水线：从选题到发布闭环
想把内容营销从“记得去发”升级成“系统按时自己跑完一轮”，关键不是单独加个提醒，而是让定时任务能领取选题、写作、部署官网、提交收录并回传发布结果。本文用 GoWork 解释这条内容流水线怎么落地。
阅读聊天渠道上下文和运行上下文有什么区别
聊天渠道上下文决定 AI 助理在和谁、在哪个入口协作；运行上下文决定它这一次执行到底带着哪些任务状态、工具结果和环境信息。本文解释两者为什么不能混为一谈，以及 GoWork 如何把它们连成可执行的协作链。
阅读失败后别重来：让 AI 助理从上次进度继续
AI 任务失败后，真正高效的做法不是每次从头再来，而是基于上次的任务状态、运行记录和已验证结果继续推进。本文解释为什么“失败续跑”是执行型 AI 助理的关键能力，以及 GoWork 如何把它落到真实工作流里。
阅读为什么 AI 助理应该在聊天里回答“任务到哪了”
用户追问“任务到哪了”时，真正需要的不是一句安慰，而是基于真实任务状态、运行历史和当前进度的可执行回答。本文解释为什么会话内任务状态，是 AI 助理走向真实协作的关键能力。
阅读为什么 AI 助理需要记忆、任务历史和回溯能力
只会当场回答的 AI 很快就会在真实协作里掉链子。要让 AI 助理真正承担跟进、续跑、回看和复盘任务，它必须同时具备记忆、任务历史和可回溯执行记录，这正是 GoWork 的核心能力之一。
阅读审批流机器人和执行型 AI 助理有什么不同
审批流机器人适合把“同意/拒绝”串进固定流程，但一旦任务需要读上下文、实际执行、跨步骤回传结果，团队真正需要的就不是审批流 Bot，而是像 GoWork 这样可持续执行的 AI 助理。
阅读在钉钉里用 GoWork 做定时提醒和自动跟进
想在钉钉里让 AI 不只会回消息，还能按时间提醒、周期巡检、命中条件后自动跟进并把结果回到原会话，关键不是接一个机器人，而是让定时任务连到执行层。本文用 GoWork 解释这套做法。
阅读如何把 GoWork 助理接进飞书：从会话到任务执行
想把 AI 助理接进飞书，不只是让它会回消息，更关键的是保留会话上下文、执行任务、创建定时提醒并把结果回传。本文用 GoWork 讲清一条可落地的接入思路。
阅读如何把 GoWork 助理接进 Telegram：从会话到定时任务
想把 AI 助理接进 Telegram，不只是让它会回消息，更关键的是保留会话上下文、执行任务、创建定时提醒并把结果回传。本文用 GoWork 讲清一条可落地的接入思路。
阅读Telegram Bot vs 常驻 AI 助理：消息入口与执行层的差别
想把 AI 接进 Telegram，很多人先想到 Bot。但如果你的需求包含上下文、工具执行、定时跟进和结果回传，你真正需要的往往不是 Telegram Bot，而是像 GoWork 这样的常驻 AI 助理。
阅读钉钉机器人 vs 常驻 AI 助理：为什么“能回消息”不等于“能做事”
想在钉钉里接入 AI，很多团队先想到机器人。但如果你的目标是持续执行任务、保留上下文、定时跟进并主动回传结果，真正需要的往往是常驻 AI 助理，而不只是机器人。
阅读用 GoWork 定时任务做巡检、日报和自动跟进
想把巡检、日报、定时提醒和条件触发自动化，关键不是单独找个提醒工具，而是让定时任务能真的执行检查、保留上下文并把结果回传。本文用 GoWork 解释一套适合运维与团队协作的做法。
阅读把 AI 助理接进钉钉/飞书/Telegram：GoWork 助理实践
想把 AI 助理接进钉钉、飞书或 Telegram，不只是“能回消息”，而是要让它保留上下文、执行任务、定时提醒并主动回传结果。本文用 GoWork 助理解释一套可落地的做法。
阅读为什么团队需要统一模型代理，而不是每个 CLI 各配一套 Key
当 Claude Code、Codex 和兼容客户端越用越多，真正失控的往往不是模型能力，而是 Key、模型名、路由和额度配置。本文解释为什么团队更需要统一模型代理，而不是每个 CLI 各配一套 Key。
阅读GoWork 模型代理：一个 localhost 端点接管所有 coding CLI
了解 GoWork 模型代理如何用一个 localhost 端点统一接入 Claude Code、Codex 等 coding CLI，集中处理账号池、密钥管理、模型映射与用量跟踪。
阅读GoWork 助手：真正会动手做事的本地 AI
GoWork 的常驻助手在你自己的机器上真正把任务做完——使用工具、保留记忆、自动定时，并委派给 Codex 与 Claude Code。它不只是一个聊天机器人。
阅读