zai-org / zai-org/feedback

[建议 / Feature] 授权制会话自动接力:额度内自动新建会话续跑长任务(条件起跑 + 消息唤醒)

Open
#344 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

priority: P2
Dominant language
No language data
Stars
22
Forks
1
PR merge metrics
No merged PRs in 30d

Description

提交前确认 · Pre-submission checklist
  • 我已搜索过现有 issue,确认这不是重复提议(最接近的 #299 是「规划会话派生便宜模型执行体」做成本分层编排;本建议关注授权额度内的会话自动接力,互补不重复)
  • 我已阅读 CONTRIBUTING.md
问题类别 · Category

对话 / Agent 交互 · Agent chat / interaction

涉及的 Agent 框架 · Agent framework

ZCode Agent(自研)

使用场景 · Use case

多阶段长程任务:单条流水线跨多个阶段、每阶段数小时,靠多个会话接力完成。

长上下文不等于长质量——模型在超长上下文下的多跳推理会衰减,所以重度用户的最佳实践是「分会话接力」:每个会话控制上下文预算,接近上限时由旧会话写一份自包含的接力提示词,开新会话注入后继续。

问题在于**「开新会话」这个动作只有用户能做**:Agent 不能在任务中途自动新建会话,预备好的会话不能等条件满足后自动起跑,挂起的会话也不能被消息唤醒。长任务的连续执行最终卡在「人必须在场按一次键」上——夜间、假期时整条流水线停摆等人。

现有 Automations 已支持「定时触发 + 每次新开会话 + 用户预写指令」,非常接近,但缺三块:

  1. 触发只有时间,没有条件/事件——无法表达「上一个会话结束时」「指定命令退出码为 0 时」「指定文件出现时」自动起跑;
  2. 指令是静态的——不能接收上一会话在运行中动态生成的接力提示词,而接力提示词恰恰必须由旧会话在收尾时基于当轮实况写就;
  3. 没有授权额度概念——要么用户每次手动、要么任务无限自主,缺少中间档「用户批 N 次、用完即停」。
建议方案 · Proposal

三条能力,可分批实现:

A. 授权制自动新建会话(配额 N):用户一次性授权「自动新建会话 N 次」。当前会话按用户预设的换会话纪律(上下文阈值、阶段完成等)自行判断需要接力时,消耗 1 次额度,自动新建一个干净会话(零背景、仅注入接力提示词)并起跑;额度耗尽即停并通知用户。

B. 条件触发:Automations 触发方式从「定时」扩展到「条件」——预建会话挂起等待,条件成立(上一会话结束信号 / 命令退出码 / 文件出现 / 组合条件)自动起跑。

C. 消息唤醒:挂起等批复的会话可被 Bot Channel 消息唤醒(例如用户在飞书回一句「同意」),带着原上下文继续执行,无需回客户端手动粘贴。

安全设计(为什么这样做仍然可控):

  • 总量权在用户:N 授权时设定,配额有界、递减、用完即停;
  • 可吊销:剩余额度随时作废;
  • 可审计:每次自动新建留痕(时间/触发原因/剩余额度),沿用 Automations 现有的运行历史可跳转机制;
  • 授权不豁免既有安全机制:自动化的只是「新建会话+注入提示词」这个机械动作,安全确认等闸门在新会话照常生效;
  • 与 Automations 现有边界自然对齐(20 条上限、本地项目、保持唤醒开关)。
预期价值 · Expected value

补全长任务连续执行的最后一环:用户睡前授权 N,Agent 跨夜多班接力,用户醒来收台账审计。用户的角色从「每次交接必须在场的操作员」升级为「定量授权+事后审计的监督者」,与 ZCode「安全可控」的产品主张一致。直接受益场景:夜间无人值守长任务、多阶段流水线交接、飞书 Remote 批复闭环。

你认为的优先级 · Your perceived priority

高 · High

你使用的 ZCode 版本 / 环境 · ZCode version / environment

v3.8.1 / macOS arm64 桌面端

补充材料 · Additional context

相关官方文档页:Automations(定时与闲时任务)、Bot Channel(飞书/微信 Bot)、安全操作确认——本建议是这三者能力的自然交汇与延伸。

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No source files, tests, or implementation entry points are named. Start by reviewing the existing Automations, Bot Channel, and security-confirmation documentation, then establish which of the three proposed capabilities is in scope. Done should be a bounded, agreed design with defined authorization, triggering, auditing, and stopping behavior.

Written by the indexing model from the issue text.

Assessment

Domain
ai, developer-experience
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.