What feature would you like to see?
我提议一个工作流编排功能，让用户能够定义和编排多阶段开发流程，比单纯的提示词和技能提供更确定、更稳定的代理行为控制。
问题陈述：
我基于 Kimi Code + Superpowers（kimi-with-superpowers）尝试构建结构化开发工作流，但现有机制无法提供稳定的流程控制：
已尝试的方案及局限性：
- Agent 提示词 - 在 system prompt 中定义 7 阶段开发流程，但 LLM 经常忽略或误解复杂的阶段指令
- Skills - 将阶段指导写入 skill 文件，但需要 LLM "主动阅读"才能生效，无法强制触发，且不同模型理解程度差异大
- Hooks 机制 (Beta) - 虽然可以拦截工具调用，但无法注入上下文提示，也无法维持跨调用的阶段状态控制
- Plan Mode - 只有简单的读写限制，没有分阶段的过程控制能力
实际遇到的问题：
- 在探索阶段未完成时，Agent 就开始写代码实现
- 跳过设计评审直接实施，导致架构问题后期返工
- 声称功能完成但未运行测试验证，实际存在回归问题
- 每个新会话都需要重新"说服" LLM 遵守流程，无法沉淀稳定的执行模式
这说明：提示词和技能是"建议"，而生产环境需要的是"编排"。当前的 plan mode 专注于规划阶段，但缺乏对实施过程的编排能力，无法保证 Agent 按预期方法论稳定执行。
建议方案：
一个轻量级工作流编排系统，允许用户定义：
- 阶段 - 具有特定任务的命名阶段（如"探索"、"规划"、"实现"、"审查"）
- 工具可见性 - 每个阶段可用的工具
- 阶段指导 - 代理在每个阶段应该做什么（注入到上下文中）
- 转换 - 如何在阶段间移动（用户确认、工具调用等）
关键设计原则：
-
控制反转：系统只提供编排机制（阶段注册、状态流转、上下文注入），用户通过 YAML 或代码定义具体工作流，实现声明式配置
-
LLM 感知：每个 LLM 回合自动注入当前阶段上下文（阶段名、任务列表、可用工具、退出条件），让代理明确知道"现在该做什么"
-
渐进式约束：阶段初期仅做提示，关键节点要求用户确认，紧急情况下允许跳过，平衡引导与灵活性
示例用例：
-
标准化开发流程：需求澄清（只读工具）→ 技术方案（写设计文档）→ 编码实现（全部工具）→ 验证交付（测试工具），每个阶段需用户确认才能推进
-
故障排查流程：信息收集 → 根因假设 → 验证测试 → 修复实施 → 回归验证，强制按顺序执行防止遗漏关键步骤
-
代码审查流程：自动分析变更 → 生成审查清单 → 逐条确认 → 汇总报告，将审查过程标准化
想请教团队的问题：
首先感谢 Kimi Code 团队一直以来的投入，以下是我诚挚想了解的几点：
1. 关于内部规划
请团队内部是否已经有类似的流程控制或多阶段工作流规划？如果有，我希望能了解方向是否一致，避免重复建设；如果暂时没有，我很想知道团队对这类需求的看法。
2. 关于可行性与技术路线
从 Kimi Code 的架构来看，基于现有的 SessionState、动态注入机制和工具集系统，实现一个用户可定义的工作流框架是否可行？技术上是否存在我未考虑到的难点或限制？团队更倾向将其作为核心功能还是通过插件/扩展机制实现？
3. 关于设计理念
团队对"工作流编排"这个设计理念有什么看法？在 AI Agent 工具的发展中，你们认为提示词/技能 vs 状态驱动的工作流编排，哪一种更符合长期方向？对于"指导"与"强制"的平衡，团队的经验和建议是什么？
愿意贡献：
如果团队认为这个方向有价值，我愿意投入时间完善原型、撰写详细设计文档，或参与任何形式的讨论。即使最终判断这个方案不适合官方路线图，也希望能得到反馈，帮助我理解更优的解决思路。
Additional information
No response
What feature would you like to see?
I propose a workflow orchestration feature that allows users to define and orchestrate multi-stage development processes, providing more certain and stable control of agent behavior than mere prompt words and skills.
Problem Statement:
I tried to build a structured development workflow based on Kimi Code + Superpowers (kimi-with-superpowers), but the existing mechanism cannot provide stable process control:
Tried solutions and limitations:
- Agent Prompt Word - Define the 7-stage development process in the system prompt, but LLM often ignores or misunderstands complex stage instructions
- Skills - Write stage guidance into the skill file, but it requires LLM "active reading" to take effect. It cannot be forcibly triggered, and the understanding level of different models varies greatly.
- Hooks mechanism (Beta) - Although tool calls can be intercepted, contextual hints cannot be injected, and phase state control across calls cannot be maintained.
- Plan Mode - only simple read and write restrictions, no phased process control capabilities
Actual problems encountered:
- Before the exploration phase is completed, the Agent starts writing code to implement it
- Skip design review and implement directly, resulting in later rework of architectural issues
- Claiming that the function is complete but not running tests to verify it, there are actually regression issues
- Each new session requires re-convincing LLM to comply with the process, and a stable execution pattern cannot be precipitated
This means: Prompt words and skills are "suggestions", while what the production environment requires is "orchestration". The current plan mode focuses on the planning phase, but lacks the ability to orchestrate the implementation process and cannot ensure that the Agent executes stably according to the expected methodology.
Suggested solution:
A lightweight workflow orchestration system that allows users to define:
- Phases - Named phases with specific tasks (e.g. "Explore", "Plan", "Implement", "Review")
- Tool Visibility - Tools available at each stage
- Phase Guidance - What the agent should do at each stage (injected into the context)
- Transitions - How to move between stages (user confirmation, tool invocation, etc.)
Key Design Principles:
-
Inversion of Control: The system only provides orchestration mechanisms (stage registration, state transfer, context injection), and users define specific workflows through YAML or code to achieve declarative configuration
-
LLM awareness: Each LLM round automatically injects the current stage context (stage name, task list, available tools, exit conditions), allowing the agent to clearly know "what to do now"
-
Progressive Constraints: Only prompts are provided at the beginning of the stage, key nodes require user confirmation, and skipping is allowed in emergencies, balancing guidance and flexibility.
Example use case:
-
Standardized development process: Requirements clarification (read-only tools) → technical solutions (writing design documents) → coding implementation (all tools) → verification delivery (testing tools), each stage requires user confirmation before progress
-
Troubleshooting process: Information collection → Root cause hypothesis → Verification testing → Repair implementation → Regression verification, forcing sequential execution to prevent missing key steps
-
Code review process: Automatically analyze changes → Generate review list → Confirm item by item → Summary report to standardize the review process
Questions to ask the team:
First of all, I would like to thank the Kimi Code team for their continued investment. Here are a few things I sincerely want to know:
1. About internal planning
Does the team already have similar process control or multi-stage workflow planning? If there is, I hope to know whether the direction is consistent to avoid duplication of construction; if there is not yet, I would like to know the team's views on such needs.
2. About feasibility and technical route
From the perspective of Kimi Code's architecture, is it feasible to implement a user-definable workflow framework based on the existing SessionState, dynamic injection mechanism and toolset system? Are there any technical difficulties or limitations that I haven't considered? Does the team prefer to implement this as a core feature or through a plug-in/extension mechanism?
3. About design concept
What does the team think of the design concept of "workflow orchestration"? In the development of AI Agent tools, which one do you think is more in line with the long-term direction: prompt words/skills vs. status-driven workflow orchestration? What is the team's experience and advice on the balance between "guidance" and "enforcement"?
Willing to contribute:
If the team thinks this direction is valuable, I'm willing to invest time in refining prototypes, writing detailed design documents, or participating in any kind of discussion. Even if it is ultimately judged that this solution is not suitable for the official roadmap, I still hope to get feedback to help me understand better solutions.
Additional information
No response
What feature would you like to see?
我提议一个工作流编排功能，让用户能够定义和编排多阶段开发流程，比单纯的提示词和技能提供更确定、更稳定的代理行为控制。
问题陈述：
我基于 Kimi Code + Superpowers（kimi-with-superpowers）尝试构建结构化开发工作流，但现有机制无法提供稳定的流程控制：
已尝试的方案及局限性：
实际遇到的问题：
这说明：提示词和技能是"建议"，而生产环境需要的是"编排"。当前的 plan mode 专注于规划阶段，但缺乏对实施过程的编排能力，无法保证 Agent 按预期方法论稳定执行。
建议方案：
一个轻量级工作流编排系统，允许用户定义：
关键设计原则：
控制反转：系统只提供编排机制（阶段注册、状态流转、上下文注入），用户通过 YAML 或代码定义具体工作流，实现声明式配置
LLM 感知：每个 LLM 回合自动注入当前阶段上下文（阶段名、任务列表、可用工具、退出条件），让代理明确知道"现在该做什么"
渐进式约束：阶段初期仅做提示，关键节点要求用户确认，紧急情况下允许跳过，平衡引导与灵活性
示例用例：
标准化开发流程：需求澄清（只读工具）→ 技术方案（写设计文档）→ 编码实现（全部工具）→ 验证交付（测试工具），每个阶段需用户确认才能推进
故障排查流程：信息收集 → 根因假设 → 验证测试 → 修复实施 → 回归验证，强制按顺序执行防止遗漏关键步骤
代码审查流程：自动分析变更 → 生成审查清单 → 逐条确认 → 汇总报告，将审查过程标准化
想请教团队的问题：
首先感谢 Kimi Code 团队一直以来的投入，以下是我诚挚想了解的几点：
1. 关于内部规划
请团队内部是否已经有类似的流程控制或多阶段工作流规划？如果有，我希望能了解方向是否一致，避免重复建设；如果暂时没有，我很想知道团队对这类需求的看法。
2. 关于可行性与技术路线
从 Kimi Code 的架构来看，基于现有的 SessionState、动态注入机制和工具集系统，实现一个用户可定义的工作流框架是否可行？技术上是否存在我未考虑到的难点或限制？团队更倾向将其作为核心功能还是通过插件/扩展机制实现？
3. 关于设计理念
团队对"工作流编排"这个设计理念有什么看法？在 AI Agent 工具的发展中，你们认为提示词/技能 vs 状态驱动的工作流编排，哪一种更符合长期方向？对于"指导"与"强制"的平衡，团队的经验和建议是什么？
愿意贡献：
如果团队认为这个方向有价值，我愿意投入时间完善原型、撰写详细设计文档，或参与任何形式的讨论。即使最终判断这个方案不适合官方路线图，也希望能得到反馈，帮助我理解更优的解决思路。
Additional information
No response
What feature would you like to see?
I propose a workflow orchestration feature that allows users to define and orchestrate multi-stage development processes, providing more certain and stable control of agent behavior than mere prompt words and skills.
Problem Statement:
I tried to build a structured development workflow based on Kimi Code + Superpowers (kimi-with-superpowers), but the existing mechanism cannot provide stable process control:
Tried solutions and limitations:
Actual problems encountered:
This means: Prompt words and skills are "suggestions", while what the production environment requires is "orchestration". The current plan mode focuses on the planning phase, but lacks the ability to orchestrate the implementation process and cannot ensure that the Agent executes stably according to the expected methodology.
Suggested solution:
A lightweight workflow orchestration system that allows users to define:
Key Design Principles:
Inversion of Control: The system only provides orchestration mechanisms (stage registration, state transfer, context injection), and users define specific workflows through YAML or code to achieve declarative configuration
LLM awareness: Each LLM round automatically injects the current stage context (stage name, task list, available tools, exit conditions), allowing the agent to clearly know "what to do now"
Progressive Constraints: Only prompts are provided at the beginning of the stage, key nodes require user confirmation, and skipping is allowed in emergencies, balancing guidance and flexibility.
Example use case:
Standardized development process: Requirements clarification (read-only tools) → technical solutions (writing design documents) → coding implementation (all tools) → verification delivery (testing tools), each stage requires user confirmation before progress
Troubleshooting process: Information collection → Root cause hypothesis → Verification testing → Repair implementation → Regression verification, forcing sequential execution to prevent missing key steps
Code review process: Automatically analyze changes → Generate review list → Confirm item by item → Summary report to standardize the review process
Questions to ask the team:
First of all, I would like to thank the Kimi Code team for their continued investment. Here are a few things I sincerely want to know:
1. About internal planning
Does the team already have similar process control or multi-stage workflow planning? If there is, I hope to know whether the direction is consistent to avoid duplication of construction; if there is not yet, I would like to know the team's views on such needs.
2. About feasibility and technical route
From the perspective of Kimi Code's architecture, is it feasible to implement a user-definable workflow framework based on the existing SessionState, dynamic injection mechanism and toolset system? Are there any technical difficulties or limitations that I haven't considered? Does the team prefer to implement this as a core feature or through a plug-in/extension mechanism?
3. About design concept
What does the team think of the design concept of "workflow orchestration"? In the development of AI Agent tools, which one do you think is more in line with the long-term direction: prompt words/skills vs. status-driven workflow orchestration? What is the team's experience and advice on the balance between "guidance" and "enforcement"?
Willing to contribute:
If the team thinks this direction is valuable, I'm willing to invest time in refining prototypes, writing detailed design documents, or participating in any kind of discussion. Even if it is ultimately judged that this solution is not suitable for the official roadmap, I still hope to get feedback to help me understand better solutions.
Additional information
No response