桌面应用【免费下载链接】EcoPaste跨平台的剪贴板管理工具 | Cross-platform clipboard management tool项目地址https://gitcode.com/ayangweb/EcoPaste点击查看免费下载本文以 EcoPaste 仓库中内置的 AI 协作技能文档 workflows.md 为主线系统讲解trellis channel多智能体协作运行时的六种标准工作流Pattern A–F。你将掌握如何按意图选择「持久化信道」与「一次性 run」、如何编排 peer 头脑风暴、派发 implement/check worker、并行评审、论坛式反馈采集以及如何接管已有线程并结合仓库内的命令参考与 Worker 机制源码级文档把每条命令写到可直接复制运行的程度。一、背景trellis channel 是什么为什么 EcoPaste 需要它trellis channel是本地多智能体协作运行时local multi-agent collaboration runtime它的核心设计是多个 Agent 通过一份**持久的、可追加的事件日志durable event log**进行对话而不是靠互相吐 prompt 碰运气。在本仓库中它被封装为可复用的技能入口说明位于 SKILL.md其中明确写道trellis channelis the local multi-agent collaboration runtime. Reach for it when agents need to talk through a durable event log, when a worker should be spawned as a peer process, when an in-flight worker needs interrupt / debugging, or when feedback should be recorded on a durable--type forumchannel.仓库的 AGENTS.md 也说明.agents/skills/目录保存的是可复用的 Trellis 技能reusable Trellis skills这些技能服务于项目中被 Codex 或其它支持 Agent 的工具驱动的开发流程。因此本文讨论的对象虽然不属于剪贴板业务代码本身但它是该项目工程化与 AI 辅助开发流程的组成部分——掌握这些工作流就能像维护主仓库代码一样规范地编排多个 Agent 完成协作任务。选择工作流的第一原则多轮、需要往返沟通的工作优先使用持久化信道durable channel只需要问一个一次性问题的场景使用channel run。SKILL.md 的索引表给出了意图到参考文档的路由规则例如和 codex/claude 讨论一下 / brainstorm对应读references/workflows.md派一个 implement/check agent对应读workflows.md后继续读references/workers.md。这说明 workflows.md 是协作编排的上层范式而命令细节由command-reference.md、workers.md、forum.md、progress-debugging.md四个底层参考支撑。二、Pattern A多轮头脑风暴Multi-round Brainstorm2.1 触发场景与完整命令序列当用户说出和 codex/claude 讨论一下、brainstorm或拉一个 agent 进来一起看时使用 Pattern A。典型命令序列如下trellis channel create brainstorm-storage-layer --by main \ --task .trellis/tasks/05-XX-storage-adapter trellis channel spawn brainstorm-storage-layer \ --agent architect --provider codex \ --file .trellis/tasks/05-XX-storage-adapter/prd.md \ --file .trellis/tasks/05-XX-storage-adapter/design.md \ --as cx-arch --timeout 30m trellis channel send brainstorm-storage-layer \ --as main --to cx-arch --text-file /tmp/brainstorm-r1.md trellis channel wait brainstorm-storage-layer \ --as main --kind done --from cx-arch --timeout 10m这段序列的四个阶段对应四条命令阶段命令作用建信道channel create创建持久化信道--task关联 Trellis 任务目录--by main标记创建者拉入 workerchannel spawn以architect为 Agent 卡片、codex为 provider 派生一个 peer 进程--as cx-arch给它稳定的信道内身份--file注入任务文档--timeout 30m设置超时发第一轮channel send以main的身份、定向发给cx-arch长文本通过--text-file传递等待答复channel wait阻塞等待cx-arch发出done事件超时 10 分钟2.2 头脑风暴的核心纪律不要一轮就停文档强调Do not stop after one answer不要收到一个回答就结束。阅读对方的答复、识别模糊地带、发出新的 probe循环往复直到产出可执行的结论executable。每次 probe 都必须要求对方给出具体的文件路径concrete file paths具体的命令commands具体的 schema被否掉的备选方案rejected alternatives会阻塞发布的问题release-blocking issues当需要一个决策时明确拒绝模棱两可的回答Reject hedging when a decision is needed。2.3 最小轮次结构Minimum Round Structure一轮合格的头脑风暴至少覆盖五个维度这是文档给出的硬性清单方向拆分Direction split这个能力应该放进已有机制还是新建一套机制MVP 边界MVP boundaryv1 做什么、v2 做什么、什么情况会迫使 v2 回退成 v1。数据契约Data contract事件events、schema、元数据metadata、状态真相源state source of truth、兼容性compatibility。CLI/UX 契约CLI / UX contract命令名、flags、错误处理、默认值、歧义处理。跨层风险与测试Cross-layer risk and tests共享助手函数、漂移点drift points、发布阻塞型测试release-blocking tests。2.4 可选追加轮次在最小结构之外文档还允许按需追加三类轮次运维轮Operations日志、调试、卡死的 worker、kill/restart、故障恢复。迁移/发布轮Migration/releasebreaking 状态、manifest、changelog、文档站点。反对意见审查Opposition review主动让 peer Agent 站在对立面攻击当前方案——这是检验方案稳健性的低成本手段。三、Pattern B派发实现/审查 AgentImplement / Check Agent当用户要求派发实现implement或审查check工作使用 Pattern B。文档给出的模板如下TASK.trellis/tasks/05-12-foo trellis channel create cr-foo --task $TASK --by main trellis channel spawn cr-foo \ --agent check \ --jsonl $TASK/check.jsonl \ --file $TASK/prd.md \ --file $TASK/design.md \ --file $TASK/implement.md \ --cwd $PWD --timeout 15m trellis channel send cr-foo --as main --to check --text-file /tmp/cr-brief.md trellis channel wait cr-foo --as main --kind done --from check --timeout 15m trellis channel messages cr-foo --kind message --from check --tag final_answer要点拆解任务目录约定.trellis/tasks/task-id/下约定存放prd.md、design.md、implement.md与check.jsonlspawn 时用--file把它们逐一注入 worker 的系统提示词。--jsonl与 Trellis manifest--jsonl $TASK/check.jsonl指向一个 Trellis 清单文件每行形如{file:path,reason:why}reason会以注释头的方式保留在注入内容上方。据 workers.md 的说明上下文加载器context-loader对每个文件有 1 MB 硬上限超限报错、200 KB 阈值给出 stderr 警告、累计 500 KB 警告并且所有注入路径必须落在--cwd之内路径穿越防护。spawned事件会同时记录字面的files数组与从--jsonl展开的manifests保证审计痕迹能还原 worker 实际看到了什么。实现与审查的分工做实现工作改用--agent implement并发送实现简报implementation brief做审查工作时必须把确切的 diff 范围、相关 spec、已经跑过的验证一并交给 check worker。这里顺带引出一个容易踩的坑最后一行的messages ... --tag final_answer只是从事件流里翻出带自定义标签的消息文本它不能作为完成信号。真正的完成信号必须是--kind done。关于tag vs kind的细节见下文第七节。四、Pattern C并行审查者Parallel Reviewers当需要多个 worker 并行评审同一份材料时使用一个信道 不同的 worker 身份名而不是为每个 reviewer 各建一个信道trellis channel create cr-feature --by main --ephemeral trellis channel spawn cr-feature --agent check \ --jsonl $TASK/check.jsonl --file $TASK/prd.md --file $TASK/design.md \ --timeout 15m trellis channel spawn cr-feature --agent check --provider codex --as check-cx \ --jsonl $TASK/check.jsonl --file $TASK/prd.md --file $TASK/design.md \ --timeout 15m trellis channel send cr-feature --as main --to check --text-file /tmp/cr-brief.md trellis channel send cr-feature --as main --to check-cx --text-file /tmp/cr-brief.md trellis channel wait cr-feature --as main --kind done --from check,check-cx --all --timeout 15m关键点--ephemeral创建的是临时信道它在channel list默认视图中隐藏也是channel prune --ephemeral的清扫目标见 command-reference.md。两个 worker 通过--as check与--as check-cx获得不同身份第二个 spawn 用--provider codex覆盖 Agent 卡片的 provider从而让claude 与 codex 两个实现各审一遍形成交叉验证。--all语义wait加上--all后--from里列出的每个 worker 都必须发出匹配事件done才算完成只要有一个还没完成就继续阻塞直到--timeout 15m超时。据 command-reference.mdwait超时统一以退出码 124结束并向 stderr 打印timeout: still waiting on ...。五、Pattern D一次性 WorkerOne-shot Worker只问一个问题、不需要多轮往返时用channel run信道会在成功后自动销毁trellis channel run --provider codex --message say hi in 3 words --timeout 1m trellis channel run --agent plan --message-file /tmp/plan-question.md --timeout 10mrun的完整机制见 command-reference.md若省略name自动生成run-hex名称内部流程是「创建 ephemeral 信道createModerun→ 派生单个 worker → 发送 prompt → 等待done→ 把最终 assistant 文本打印到 stdout → 成功后删除信道」。成功run移除临时信道stdout 只输出最终文本便于管道化诊断信息走 stderr。失败/超时/被 killrun保留信道并打印其路径供检查退出码为 1。run同样没有--tag概念完成检测依赖 supervisor 发出的done事件。六、Pattern E 与 F论坛信道与接管已有线程6.1 Pattern EForum Channel论坛信道Pattern E 适用于issue 论坛、按主题组织的反馈、发布待办release todos、Agent 发现记录、内部 changelog。它指向完整的模型文档 forum.md核心模型如下信道类型在channel create时用--type forum决定且不可变chat默认平铺消息时间线与forum线程导向messages无过滤时渲染线程看板而非事件流。线程用稳定的--thread key标识惯例是 kebab-case 小写首个动作是opened之后所有动作复用同一 key。常用动作opened、comment、status、summary、labels、assignees、processed。--labels/--assignees是替换语义replace不是 append--description是持久的线程描述--summary是滚动总结在status closed时写 summary 是标记线程已解决的标准做法。读取路径是看板摘要 → 单线程时间线 → 当前上下文禁止直接解析events.jsonl。内部 changelog 的典型用法全局论坛信道 每个值得记录的变更一个线程如release-2026-q1、runtime-event-schema-change。一个可运行的论坛创建与开帖示例据 forum.mdtrellis channel create design-feedback \ --type forum --scope global \ --description Cross-project design feedback board. \ --context-raw One thread per design topic; close when resolved. \ --by main trellis channel post design-feedback opened \ --scope global --as main \ --thread login-empty-state \ --title Empty state on the login screen \ --description Track design feedback for the new login empty state. \ --labels design,login \ --text-file /tmp/thread-open.md6.2 Pattern F接管已有线程Take Over Existing Thread当用户给了一个 forum/thread 名称时不要问背景自己恢复上下文trellis channel forum board --scope global trellis channel thread board thread --scope global --raw trellis channel context list board --scope global --thread thread trellis channel messages board --scope global --raw --thread thread恢复上下文后输出一份约束摘要constraint summary而不是转储记录transcript dump摘要必须覆盖五个要素用户层面的问题user-level problem会影响本仓库的上下文文件context files that affect this repo当前版本 vs 未来版本的需求current-version versus future-version requirements当前代码/设计是否满足该需求下一步行动或要追加的评论next action or comment to append七、横切原则完成信号、身份、作用域与投递语义以下原则贯穿全部六个 Pattern部分内容来自 workflows.md 与 SKILL.md 的 Core Rules也有来自命令级参考的硬事实7.1 用系统事件做完成信号不依赖自定义 tagDispatcher wait 模式wait的完成信号必须用--kind done或--kind turn_finished——这是 supervisor 自动发出的 trellis 系统事件。不要依赖 worker 去执行send --tag my_signal来宣告完成LLM worker 常常把 tag 字符串写进散文而不是真的跑 CLI 命令可靠性极差。command-reference.md 进一步说明--kind是唯一的事件类型过滤器取值被白名单CHANNEL_EVENT_KINDS约束create, join, leave, message, thread, context, channel, spawned, killed, respawned, progress, done, error, waiting, awake, undeliverable, interrupt_requested, turn_started, turn_finished, interrupted, supervisor_warning传其它值会抛Invalid --kind x. Must be one of: …。send与run没有任何--tag/--kind发射能力——每次send只写出一条message事件。中途打断 worker 也不是 tag而是独立的channel interrupt命令它追加interrupt_requested/interrupted事件对并做 provider 级打断。7.2--as的两种含义与作用域模型--as在send/wait/interrupt里是发言者身份在spawn里是worker 句柄其它 Agent 用--to寻址的名字。多个 Agent/会话参与时必须用显式、稳定的名字见 workers.md。--scope project默认作用于当前 cwd 的项目桶--scope global作用于共享的__global__桶。全局看板在项目列表里不可见除非显式传--scope global。7.3 投递与唤醒语义worker 派生后默认收件箱空闲inbox-idle直到第一次send --to worker或配置了--inbox-policy broadcastAndExplicit时收到广播才会被唤醒。投递校验由send --delivery-mode控制appendOnly无条件追加事件。requireKnownWorker若--to指名的 worker 从未spawned过则报错。requireRunningWorker若指名的 worker 当前未存活则报错——更严格的投递模式可以防止发给一个并不在场的 peer导致的静默丢消息。一个典型的 dispatcher 循环据 workers.md# 1. 唤醒 worker要求它必须存活 echo Run the failing test and report. \ | trellis channel send impl-task --as dispatcher --to codex-impl --stdin \ --delivery-mode requireRunningWorker # 2. 阻塞直到完成或出错 trellis channel wait impl-task --as dispatcher \ --from codex-impl --kind done,error --timeout 30m # 3. 读取最终答案 trellis channel messages impl-task --from codex-impl --last 1 --raw7.4 软打断与硬打断软打断channel interrupt追加interrupt事件reasonuser并在 adapter 支持时Claude/interrupt、Codex turn cancel做 provider 级打断worker 丢弃当前回合立即按新指令行动会话不丢。硬打断channel kill用于必须立刻停止的场景supervisor 走 SIGTERM → 8 秒宽限 → SIGKILL 升级--force立即 SIGKILL。kill会清理pid/worker-pid/config/spawnlock副产物文件但保留log/session-id/thread-id供取证与--resume续跑。当 interrupt 无法收敛时kill --resume是有保证的改道路径。八、资源保护Worker OOM 守卫每次spawn都会运行 OOM 守卫防止孤儿/空闲 worker 堆积耗尽宿主机资源见 workers.md空闲 TTL清扫最近活动早于阈值的 worker默认5m0关闭。存活预算同项目桶内存活 worker 超过 N 则拒绝新 spawn默认60关闭。配置优先级高→低spawn的 CLI flags--idle-timeout/--max-live-workers→ 环境变量TRELLIS_CHANNEL_WORKER_IDLE_TIMEOUT/TRELLIS_CHANNEL_MAX_LIVE_WORKERS→.trellis/config.yaml#channel.worker_guard→ 内置默认值。清理通知会写到 stderrephemeral 与channel runworker 同样受空闲 TTL 与预算约束。九、排查与审计接口worker 卡住、进度被截断、want 一直超时时按 progress-debugging.md 的纪律处理pretty 是操作台--raw是审计日志。messages --raw按行输出与events.jsonl完全一致的 JSON不会丢任何字段进度文本被截断时永远改用--raw --kind progress复查。卡死诊断顺序list --all --all-projects定位信道 →cat $CHAN/worker.pid/ps确认 supervisor 与子进程存活supervisor 没了就是幽灵条目用kill --force清理→tail -f $CHAN/worker.log看 provider/MCP/工具启动输出 →messages --raw --last 50看最后事件。论坛信道永远不要直接 grepevents.jsonl一个文件里混着多个逻辑线程手拆必然把线程混成一团、丢失生命周期事件、无视 worker 的inbox-cursor。统一走forum、thread、messages --thread、context list这些有状态的投影视图。信道存储布局为~/.trellis/channels/bucket/channel-name/内含events.jsonl、channel.lock、worker.log、worker.pid、worker.worker-pid、worker.session-id、worker.thread-id、worker.inbox-cursor等文件——Agent 平时用 CLI不直接读文件。十、快速决策表六种模式怎么选场景模式一句话要点和 codex/claude 讨论一下、brainstormPattern A建持久信道 派生 architect peer 多轮 probe直到可执行派实现/审查工作Pattern B--agent implement/--agent check--jsonl/--file注入 --kind done等待多 Agent 并行评审Pattern C单信道 不同--as身份 wait --all等齐所有人一次性问答Pattern Dchannel run成功即销毁临时信道失败保留现场论坛/发布记录/反馈采集Pattern E--type forumopened开线程status/summary收尾接管已有线程Pattern F先恢复上下文输出约束摘要而非转储十一、进一步阅读workflows.md —— 本文的权威来源六个 Pattern 的完整命令序列。command-reference.md —— 每个子命令、每个 flag、作用域/类型模型、事件模型与输出约定。workers.md —— spawn 机制、Agent 卡片、上下文注入、软/硬打断、OOM 守卫、收件箱 API。forum.md —— 论坛信道的线程模型、上下文管理与删除纪律。progress-debugging.md —— pretty/raw 视图、卡死诊断、事件语义与常见故障表。SKILL.md —— 技能索引、意图路由表与 Core Rules。需要特别说明的边界本文所有命令与参数均以当前仓库中上述参考文档的描述为准.trellis/tasks/、~/.trellis/channels/等路径是 Trellis 管理项目与本地运行时的约定目录实际使用 Trellis 时才会生成。若你的开发环境中尚无trellis命令需要先安装 CLI 才能运行文中示例。赞分享桌面应用【免费下载链接】EcoPaste跨平台的剪贴板管理工具 | Cross-platform clipboard management tool项目地址https://gitcode.com/ayangweb/EcoPaste点击查看免费下载相关推荐Trellis Channel 多代理协作工作流实战六种模式与命令级操作指南Trellis Channel 多代理协作工作流实战六种模式与命令级操作指南 导读 本文是 trellis channel skill 中 workflows桌面应用EcoPaste 项目中的 Trellis Channel CLI 完全命令参考多智能体协作运行时实战指南EcoPaste 项目中的 Trellis Channel CLI 完全命令参考多智能体协作运行时实战指南 本文是 EcoPaste 仓库内 .agents/桌面应用Trellis Channel 多智能体协作运行时实战从频道命令到事件级排障的完整指南Trellis Channel 多智能体协作运行时实战从频道命令到事件级排障的完整指南 导读 Trellis Channel 是 Trellis 的本地多智能桌面应用上一篇3个核心功能揭秘如何用Python自动化B站会员购抢票下一篇biliTickerBuy项目解析三步掌握B站会员购自动化抢票技术创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考