AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载导读本文聚焦 Kimi Codeagent-core-v2中的目标Goal功能子系统及其入口工具CreateGoal从该工具的官方提示词文档出发系统讲解何时应该创建目标、何时必须拒绝创建、objective与completionCriterion的撰写规范、replace替换语义并结合仓库源码create-goal.md、create-goal.ts、createGoalTool.ts、goalService.ts逐层拆解参数校验、主 Agent 限制、状态快照与过期调用保护等实现细节。读完本文你将完整掌握 Kimi Code 自主目标生命周期的起点以及如何正确驱动 Agent 跨多轮次持续完成一项可验证的任务。一、背景Goal 子系统在 agent-core-v2 中的定位在packages/agent-core-v2中目标功能被设计为一个独立的 FeatureGoalFeature见 goalFeature.ts它向运行时贡献一个目标服务IAgentGoalService和四个目标工具工具名领域职责CreateGoalgoal创建一个持久、结构化的目标启动跨多轮次的自主执行GetGoalgoal读取当前目标及其状态快照SetGoalBudgetgoal为目标设置 token / 轮次 / 墙钟时间预算UpdateGoalgoal修改目标状态active恢复、complete完成、blocked阻塞CreateGoal是所有目标工作流的起点没有目标运行时就没有跨轮次持续执行的载体一旦目标建立runtime 会在每轮结束后自动注入goal_continuation提示见 goalService.ts驱动 Agent 持续朝目标推进。本文讨论的 create-goal.md 正是该工具注入给模型LLM的官方描述文本即模型决定要不要、以及如何创建目标时的行为准则。二、CreateGoal 的使用时机什么情况才应该创建目标官方描述给出了两条允许创建的判据只有满足其一才应调用CreateGoal用户明确要求用户显式要求 Agent 启动一个目标或要求其自主autonomously朝某个结果持续工作宿主目标启动提示存在一个来自宿主host的 goal-intake prompt要求创建目标。同时官方描述明确划出了禁止创建的红线并给出原因——目标必须有一个可核验的结束状态checkable end state问候语greetings普通问答ordinary questions缺乏可验证完成条件的模糊请求vague requests。2.1 模糊请求的处置流程当请求语义模糊、缺少完成判据时工具的使用规范要求模型先向用户索要缺失的完成标准再创建目标而不是擅自替用户发明验收条件。这是可核验结束状态这一核心原则的直接体现没有明确的完成判据运行时就无法判断目标何时收敛也无法在UpdateGoal中给出complete的机器可读信号见 update-goal.md。规范同时留有一个例外通道如果模型已经明确警告用户该表述模糊或存在风险而用户仍然坚持那么必须尊重用户意愿照常创建目标——即警告之后尊重用户决定权。2.2 为什么普通问答不应该创建目标从实现上看目标一旦创建运行时会把它当作长期状态持续驱动每轮结束handleTurnEnded且目标仍为active时launchContinuationTurn 会立即向 loop 提交新的goal_continuation用户消息形成自动续跑循环。若对一次性问答创建目标会让 Agent 陷入无意义的持续执行浪费预算并偏离用户真实意图。这正是描述文本反复强调目标需要可核验结束状态的底层原因。三、输入参数详解objective、completionCriterion 与 replace工具参数的官方 schema 定义在 create-goal.ts由CreateGoalToolInputSchema提供并通过toInputJsonSchema转成 JSON Schema 注入工具描述export const CreateGoalToolInputSchema z .object({ objective: z.string().min(1).describe(The objective to pursue. Must have a verifiable end state.), completionCriterion: z .string() .optional() .describe(How to verify the goal is complete. Include when the user provides one.), replace: z .boolean() .optional() .describe(Replace an existing active, paused, or blocked goal instead of failing.), }) .strict();3.1objective必填必须是非空字符串z.string().min(1)描述要追求的目标且必须具有可验证的结束状态官方描述要求保持简洁长任务描述应通过文件路径引用reference long task descriptions by file path rather than pasting them而不是把大段文本粘贴进 objective。从源码看这一约束不只是提示词层面的建议而是硬校验。goalService.ts中的validateObjectivegoalService.ts会对 objective 做trim()并强制长度上限MAX_GOAL_OBJECTIVE_LENGTH 4000字符超长时抛出ErrorCodes.GOAL_OBJECTIVE_TOO_LONG错误信息本身也引导模型把长内容放进文件并引用文件路径。这与文档规范完全一致属于文档建议 运行时强制的双保险。3.2completionCriterion可选描述如何验证目标已完成官方规范当用户提供了完成判据时必须带上或者当它可以在不凭空发明新需求的前提下陈述时也应当带上。运行时对它的处理同样发生在createGoal中normalizeCompletionCriterion(input.completionCriterion)goalService.ts会规范化后存入目标状态。该判据随后会成为 GoalSnapshot 的一个字段并在UpdateGoal的完成审计completion audit中作为模型自我核验的基准。3.3replace可选布尔值默认情况下不传或传false如果已存在一个目标创建会直接失败仅当用户明确要求放弃当前目标、开启新目标时才应使用replace: true。这一语义在 goalService.ts 的prepareForGoalCreation中实现若当前已存在目标且replace为假抛出ErrorCodes.GOAL_ALREADY_EXISTSA goal already exists; use replace to start a new one若replace为真则先执行clearInternal(context, system)清空旧目标再创建新目标。四、运行时行为创建流程与模型可见输出4.1 创建链路CreateGoalTool.resolveExecutioncreateGoalTool.ts是工具执行的入口执行链路如下主 Agent 校验调用mainAgentOnlyExecution若当前上下文不是主 Agent则直接返回错误输出Goal tools are only supported by the main agent.见 mainAgentOnly.ts——目标功能仅对主 Agent 开放子 Agent / fork 不允许创建目标解析期目标快照记录goalAtResolution用于后续判断目标是否在解析与执行之间被改变执行期并发保护执行时重新读取当前目标如果goalId与解析期不一致且新目标不是本轮由本工具创建的返回Goal not created: the current goal changed.防止迟到的工具调用污染新目标状态真正创建调用goalService.createGoal({ objective, completionCriterion, replace }, model)其中 actor 固定为model即模型发起的创建内部完成校验 objective →prepareForGoalCreationreplace 语义→ dispatchGoalCreate事件生成randomUUID()作为 goalId→ 记录墙钟起点 → 采纳起始轮次 → 刷新截止时间 → 发送GoalUpdated事件 → 上报goal_created遥测返回模型可见快照JSON.stringify({ goal: goalForModel(snapshot) }, null, 2)其中 goalForModel 会剥离内部goalId只把objective、completionCriterion、status、turnsUsed、tokensUsed、wallClockMs、budget、terminalReason等字段暴露给模型。4.2 创建后的状态快照创建成功后的GoalSnapshot包含以下核心字段types.ts字段说明objective目标描述≤ 4000 字符completionCriterion完成判据可选status目标状态active/paused/blocked/complete创建后为activeturnsUsed/tokensUsed已消耗的轮次与 token 数初始为 0wallClockMs已消耗的墙钟时间毫秒budget预算报告token / 轮次 / 墙钟三类预算及余量terminalReason终态原因完成 / 阻塞时的说明4.3 界面展示与审批当权限模式不是auto时resolveGoalStartDisplaycreateGoalTool.ts会生成一个goal_start类型的展示对象包含 objective、completionCriterion 与当前权限模式供前端在审批界面呈现即将开启的目标审批规则为工具名CreateGoal。也就是说在需要确认的权限模式下创建目标本身会经过用户审批流程。五、过期调用保护为什么测试覆盖了目标已改变场景由于目标状态是全局唯一的同一时刻只允许一个当前目标CreateGoal的执行存在天然的时间窗口竞态模型可能在同一个 batch 里先规划了创建随后目标已被替换或清除。仓库测试对这类场景有专门覆盖见 goal-tools.test.ts对替换目标不生效L67-L87解析期目标是old task执行期目标已被replace: true换成new task此时旧调用返回Goal not created: the current goal changed.且最终目标保持为new task对外部创建的目标不生效L89-L108解析时无目标执行时目标已被外部创建同样返回current goal changed不会覆盖外部目标。这类测试验证的正是resolveExecution中第 2、3 步的并发保护逻辑createGoalTool.ts保证迟到的CreateGoal调用不会错误地覆盖一个更新的目标。与之配套goalService.ts的isStaleGoalToolCallgoalService.ts还会在工具执行前拦截所有目标变更类工具含 CreateGoal的过期调用统一输出Goal changed since this turn started; ignored stale goal tool call.。六、与相邻工具的配合目标的完整生命周期CreateGoal只是目标生命周期的第一步理解它的边界需要同时了解同一子系统内的其他工具均注册于 goalFeature.tsGetGoal读取当前目标快照用于模型自查当前目标状态与预算余量SetGoalBudget为目标设置tokenBudget/turnBudget/wallClockBudgetMs上限预算耗尽会自动把目标置为blocked见blockIfBudgetReachedgoalService.tsUpdateGoal在目标运行中将其置为active恢复、complete完成或blocked阻塞。其描述文档update-goal.md对complete与blocked有严格的审计要求只有全部工作完成、显式验证通过、且无有用下一步时才可complete非终态阻塞必须连续 3 个目标轮次复现才允许blocked。官方描述中创建目标失败于已存在目标的规则也决定了CreateGoal与UpdateGoal的配合方式换目标不是先删再建而是要么replace: true直接替换要么通过UpdateGoal把旧目标终结complete/blocked后再创建新目标。七、最佳实践小结综合官方描述与源码实现使用CreateGoal的实践要点如下只在明确授权时创建用户显式要求启动目标 / 自主工作或宿主 goal-intake prompt 要求时问候、普通问答、无完成判据的模糊请求一律不创建。模糊请求先澄清缺完成标准时先向用户索要警告过风险而用户仍坚持时尊重用户并创建。objective 短而可验证必须包含可核验的结束状态长度上限 4000 字符长文按文件路径引用避免粘贴大段文本。completionCriterion 按需携带用户给了就带上能不加需求地陈述时也带上它是后续完成审计的基准。replace 仅在用户明确要求换目标时使用默认已存在目标会报GOAL_ALREADY_EXISTS不会静默覆盖。牢记主 Agent 限制目标工具仅主 Agent 可用子 Agent 调用会被拒绝Goal tools are only supported by the main agent.。配合预算与状态工具创建后用SetGoalBudget设预算、用GetGoal自查、用UpdateGoal收敛状态形成创建 → 推进 → 完成/阻塞的闭环。以上所有规则均可回溯到仓库中的文档、Schema、服务实现与测试用例可作为开发者在 Kimi Code 之上构建自主 Agent 工作流时的直接依据。赞分享AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载相关推荐Kimi Code 定时任务删除指南CronDelete 工具的使用规则与底层实现剖析Kimi Code 定时任务删除指南CronDelete 工具的使用规则与底层实现剖析 定时任务Cron是 agent core v2 会话内调度能力的核AI Agent代码智能体人工智能大模型CLIOpen Interpreter 的 kimi-cli 线束拆解「Kimi Code CLI」系统提示词模板与其运行时注入机制Open Interpreter 的 kimi cli 线束拆解「Kimi Code CLI」系统提示词模板与其运行时注入机制 本文以 codex rs/co人工智能大模型AI Agent代码智能体AI 应用CLItldraw/validate 行为规范深度解析tldraw 运行时校验库的规则体系与实现原理tldraw/validate 行为规范深度解析tldraw 运行时校验库的规则体系与实现原理 导读 本文以 packages/validate/SPEC.前端UI组件上一篇B站视频转文字用bili2text轻松搞定内容提取难题下一篇终极跨平台硬件调优指南如何用Universal x86 Tuning Utility释放处理器全部潜能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Kimi Code Agent 目标系统深入解析：CreateGoal 工具的使用规则与运行时实现
AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载导读本文聚焦 Kimi Codeagent-core-v2中的目标Goal功能子系统及其入口工具CreateGoal从该工具的官方提示词文档出发系统讲解何时应该创建目标、何时必须拒绝创建、objective与completionCriterion的撰写规范、replace替换语义并结合仓库源码create-goal.md、create-goal.ts、createGoalTool.ts、goalService.ts逐层拆解参数校验、主 Agent 限制、状态快照与过期调用保护等实现细节。读完本文你将完整掌握 Kimi Code 自主目标生命周期的起点以及如何正确驱动 Agent 跨多轮次持续完成一项可验证的任务。一、背景Goal 子系统在 agent-core-v2 中的定位在packages/agent-core-v2中目标功能被设计为一个独立的 FeatureGoalFeature见 goalFeature.ts它向运行时贡献一个目标服务IAgentGoalService和四个目标工具工具名领域职责CreateGoalgoal创建一个持久、结构化的目标启动跨多轮次的自主执行GetGoalgoal读取当前目标及其状态快照SetGoalBudgetgoal为目标设置 token / 轮次 / 墙钟时间预算UpdateGoalgoal修改目标状态active恢复、complete完成、blocked阻塞CreateGoal是所有目标工作流的起点没有目标运行时就没有跨轮次持续执行的载体一旦目标建立runtime 会在每轮结束后自动注入goal_continuation提示见 goalService.ts驱动 Agent 持续朝目标推进。本文讨论的 create-goal.md 正是该工具注入给模型LLM的官方描述文本即模型决定要不要、以及如何创建目标时的行为准则。二、CreateGoal 的使用时机什么情况才应该创建目标官方描述给出了两条允许创建的判据只有满足其一才应调用CreateGoal用户明确要求用户显式要求 Agent 启动一个目标或要求其自主autonomously朝某个结果持续工作宿主目标启动提示存在一个来自宿主host的 goal-intake prompt要求创建目标。同时官方描述明确划出了禁止创建的红线并给出原因——目标必须有一个可核验的结束状态checkable end state问候语greetings普通问答ordinary questions缺乏可验证完成条件的模糊请求vague requests。2.1 模糊请求的处置流程当请求语义模糊、缺少完成判据时工具的使用规范要求模型先向用户索要缺失的完成标准再创建目标而不是擅自替用户发明验收条件。这是可核验结束状态这一核心原则的直接体现没有明确的完成判据运行时就无法判断目标何时收敛也无法在UpdateGoal中给出complete的机器可读信号见 update-goal.md。规范同时留有一个例外通道如果模型已经明确警告用户该表述模糊或存在风险而用户仍然坚持那么必须尊重用户意愿照常创建目标——即警告之后尊重用户决定权。2.2 为什么普通问答不应该创建目标从实现上看目标一旦创建运行时会把它当作长期状态持续驱动每轮结束handleTurnEnded且目标仍为active时launchContinuationTurn 会立即向 loop 提交新的goal_continuation用户消息形成自动续跑循环。若对一次性问答创建目标会让 Agent 陷入无意义的持续执行浪费预算并偏离用户真实意图。这正是描述文本反复强调目标需要可核验结束状态的底层原因。三、输入参数详解objective、completionCriterion 与 replace工具参数的官方 schema 定义在 create-goal.ts由CreateGoalToolInputSchema提供并通过toInputJsonSchema转成 JSON Schema 注入工具描述export const CreateGoalToolInputSchema z .object({ objective: z.string().min(1).describe(The objective to pursue. Must have a verifiable end state.), completionCriterion: z .string() .optional() .describe(How to verify the goal is complete. Include when the user provides one.), replace: z .boolean() .optional() .describe(Replace an existing active, paused, or blocked goal instead of failing.), }) .strict();3.1objective必填必须是非空字符串z.string().min(1)描述要追求的目标且必须具有可验证的结束状态官方描述要求保持简洁长任务描述应通过文件路径引用reference long task descriptions by file path rather than pasting them而不是把大段文本粘贴进 objective。从源码看这一约束不只是提示词层面的建议而是硬校验。goalService.ts中的validateObjectivegoalService.ts会对 objective 做trim()并强制长度上限MAX_GOAL_OBJECTIVE_LENGTH 4000字符超长时抛出ErrorCodes.GOAL_OBJECTIVE_TOO_LONG错误信息本身也引导模型把长内容放进文件并引用文件路径。这与文档规范完全一致属于文档建议 运行时强制的双保险。3.2completionCriterion可选描述如何验证目标已完成官方规范当用户提供了完成判据时必须带上或者当它可以在不凭空发明新需求的前提下陈述时也应当带上。运行时对它的处理同样发生在createGoal中normalizeCompletionCriterion(input.completionCriterion)goalService.ts会规范化后存入目标状态。该判据随后会成为 GoalSnapshot 的一个字段并在UpdateGoal的完成审计completion audit中作为模型自我核验的基准。3.3replace可选布尔值默认情况下不传或传false如果已存在一个目标创建会直接失败仅当用户明确要求放弃当前目标、开启新目标时才应使用replace: true。这一语义在 goalService.ts 的prepareForGoalCreation中实现若当前已存在目标且replace为假抛出ErrorCodes.GOAL_ALREADY_EXISTSA goal already exists; use replace to start a new one若replace为真则先执行clearInternal(context, system)清空旧目标再创建新目标。四、运行时行为创建流程与模型可见输出4.1 创建链路CreateGoalTool.resolveExecutioncreateGoalTool.ts是工具执行的入口执行链路如下主 Agent 校验调用mainAgentOnlyExecution若当前上下文不是主 Agent则直接返回错误输出Goal tools are only supported by the main agent.见 mainAgentOnly.ts——目标功能仅对主 Agent 开放子 Agent / fork 不允许创建目标解析期目标快照记录goalAtResolution用于后续判断目标是否在解析与执行之间被改变执行期并发保护执行时重新读取当前目标如果goalId与解析期不一致且新目标不是本轮由本工具创建的返回Goal not created: the current goal changed.防止迟到的工具调用污染新目标状态真正创建调用goalService.createGoal({ objective, completionCriterion, replace }, model)其中 actor 固定为model即模型发起的创建内部完成校验 objective →prepareForGoalCreationreplace 语义→ dispatchGoalCreate事件生成randomUUID()作为 goalId→ 记录墙钟起点 → 采纳起始轮次 → 刷新截止时间 → 发送GoalUpdated事件 → 上报goal_created遥测返回模型可见快照JSON.stringify({ goal: goalForModel(snapshot) }, null, 2)其中 goalForModel 会剥离内部goalId只把objective、completionCriterion、status、turnsUsed、tokensUsed、wallClockMs、budget、terminalReason等字段暴露给模型。4.2 创建后的状态快照创建成功后的GoalSnapshot包含以下核心字段types.ts字段说明objective目标描述≤ 4000 字符completionCriterion完成判据可选status目标状态active/paused/blocked/complete创建后为activeturnsUsed/tokensUsed已消耗的轮次与 token 数初始为 0wallClockMs已消耗的墙钟时间毫秒budget预算报告token / 轮次 / 墙钟三类预算及余量terminalReason终态原因完成 / 阻塞时的说明4.3 界面展示与审批当权限模式不是auto时resolveGoalStartDisplaycreateGoalTool.ts会生成一个goal_start类型的展示对象包含 objective、completionCriterion 与当前权限模式供前端在审批界面呈现即将开启的目标审批规则为工具名CreateGoal。也就是说在需要确认的权限模式下创建目标本身会经过用户审批流程。五、过期调用保护为什么测试覆盖了目标已改变场景由于目标状态是全局唯一的同一时刻只允许一个当前目标CreateGoal的执行存在天然的时间窗口竞态模型可能在同一个 batch 里先规划了创建随后目标已被替换或清除。仓库测试对这类场景有专门覆盖见 goal-tools.test.ts对替换目标不生效L67-L87解析期目标是old task执行期目标已被replace: true换成new task此时旧调用返回Goal not created: the current goal changed.且最终目标保持为new task对外部创建的目标不生效L89-L108解析时无目标执行时目标已被外部创建同样返回current goal changed不会覆盖外部目标。这类测试验证的正是resolveExecution中第 2、3 步的并发保护逻辑createGoalTool.ts保证迟到的CreateGoal调用不会错误地覆盖一个更新的目标。与之配套goalService.ts的isStaleGoalToolCallgoalService.ts还会在工具执行前拦截所有目标变更类工具含 CreateGoal的过期调用统一输出Goal changed since this turn started; ignored stale goal tool call.。六、与相邻工具的配合目标的完整生命周期CreateGoal只是目标生命周期的第一步理解它的边界需要同时了解同一子系统内的其他工具均注册于 goalFeature.tsGetGoal读取当前目标快照用于模型自查当前目标状态与预算余量SetGoalBudget为目标设置tokenBudget/turnBudget/wallClockBudgetMs上限预算耗尽会自动把目标置为blocked见blockIfBudgetReachedgoalService.tsUpdateGoal在目标运行中将其置为active恢复、complete完成或blocked阻塞。其描述文档update-goal.md对complete与blocked有严格的审计要求只有全部工作完成、显式验证通过、且无有用下一步时才可complete非终态阻塞必须连续 3 个目标轮次复现才允许blocked。官方描述中创建目标失败于已存在目标的规则也决定了CreateGoal与UpdateGoal的配合方式换目标不是先删再建而是要么replace: true直接替换要么通过UpdateGoal把旧目标终结complete/blocked后再创建新目标。七、最佳实践小结综合官方描述与源码实现使用CreateGoal的实践要点如下只在明确授权时创建用户显式要求启动目标 / 自主工作或宿主 goal-intake prompt 要求时问候、普通问答、无完成判据的模糊请求一律不创建。模糊请求先澄清缺完成标准时先向用户索要警告过风险而用户仍坚持时尊重用户并创建。objective 短而可验证必须包含可核验的结束状态长度上限 4000 字符长文按文件路径引用避免粘贴大段文本。completionCriterion 按需携带用户给了就带上能不加需求地陈述时也带上它是后续完成审计的基准。replace 仅在用户明确要求换目标时使用默认已存在目标会报GOAL_ALREADY_EXISTS不会静默覆盖。牢记主 Agent 限制目标工具仅主 Agent 可用子 Agent 调用会被拒绝Goal tools are only supported by the main agent.。配合预算与状态工具创建后用SetGoalBudget设预算、用GetGoal自查、用UpdateGoal收敛状态形成创建 → 推进 → 完成/阻塞的闭环。以上所有规则均可回溯到仓库中的文档、Schema、服务实现与测试用例可作为开发者在 Kimi Code 之上构建自主 Agent 工作流时的直接依据。赞分享AI Agent代码智能体人工智能大模型CLI【免费下载链接】kimi-codeKimi Code CLI — The Starting Point for Next-Gen Agents项目地址https://gitcode.com/gh_mirrors/ki/kimi-code点击查看免费下载相关推荐Kimi Code 定时任务删除指南CronDelete 工具的使用规则与底层实现剖析Kimi Code 定时任务删除指南CronDelete 工具的使用规则与底层实现剖析 定时任务Cron是 agent core v2 会话内调度能力的核AI Agent代码智能体人工智能大模型CLIOpen Interpreter 的 kimi-cli 线束拆解「Kimi Code CLI」系统提示词模板与其运行时注入机制Open Interpreter 的 kimi cli 线束拆解「Kimi Code CLI」系统提示词模板与其运行时注入机制 本文以 codex rs/co人工智能大模型AI Agent代码智能体AI 应用CLItldraw/validate 行为规范深度解析tldraw 运行时校验库的规则体系与实现原理tldraw/validate 行为规范深度解析tldraw 运行时校验库的规则体系与实现原理 导读 本文以 packages/validate/SPEC.前端UI组件上一篇B站视频转文字用bili2text轻松搞定内容提取难题下一篇终极跨平台硬件调优指南如何用Universal x86 Tuning Utility释放处理器全部潜能创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考