Help shape LoopX’s capable manager and semantic handoff / 一起做能干活、不丢上下文的管家

[huangruiteng]

I want LoopX's manager to do more of the work around working with agents: investigate, understand what should happen next, find the right collaborator, and bring the result back.

We have merged the bilingual design RFC in #4330. The design is now in the repository; this is an invitation to help shape and implement it, not a claim that the proposed capabilities have shipped.

One journey we want to make reliable

You ask the manager to investigate a PR. Then you add two constraints and rule out one approach. It hands the work to another agent. The receiving session is later replaced. The work still continues with the current constraints, evidence and commitments—and the conclusion comes back without you asking again.

That journey connects three things:

• A capable host manager: use ordinary authorized runtime tools and skills to investigate, rather than needing a bespoke manager API for every resource.
• Semantic handoff: preserve why the work exists, what changed, what has been decided and what remains unresolved. The receiver assesses the request and owns its replanning; delivery is not automatic acceptance or an ownership transfer.
• Durable continuation and return: retain work-state and result evidence across sessions, interruptions and channels, with distinct execution and delivery receipts.

An always-available agent is useful. A long-horizon collaborator also needs to preserve the work when the conversation, session or executor changes. This is the part I want LoopX to make easier.

Where your input would help

1. Share a workflow or counterexample. Where do your agents lose corrections, repeat a rejected approach, choose the wrong collaborator, or finish without returning the result?
2. Challenge the design. What should a handoff preserve? How should a busy receiver defer work? Which private/shared audience or uncertain-delivery case are we missing?
3. Build or validate a slice. Host/runtime integration, TypeScript request transactions, frontend/Lark feedback, migration and recovery tests all have useful work. M1 investigation and independent reply recovery need not wait for the full M2 refactor.

You do not need to read every related RFC before joining. Start with the decision summary, the A1–A16 user journeys, or one problem you can reproduce. Please use public/synthetic examples rather than private transcripts or credentials.

Read the RFC in English · 阅读中文版 · Coordinate implementation / 参与实现：#4339

中文：一起做一个能调查、能交接、能把结果带回来的管家

我希望 LoopX 管家能少让人做几件事：反复补背景、手动找 Agent、重复解释约束，以及追问“刚才那件事结果呢”。

举个例子：你让管家调查一个 PR，后来补充两条约束、否决一条路线。管家把工作交给另一个 Agent，中间换了 session，接收方仍然知道为什么做、什么不能做、哪些证据有效，并在完成后自动回报。

这需要把几件事一起做好：管家有充分的普通工具调查能力；交接保留工作的意义，而不只转发原句；接收方能结合自己已接受的工作重新规划；结果、送达和恢复分别有据可查。Goal/Todo/Vision/lease 继续由现有工作状态权威管理，不另外造一套任务系统。

常驻解决随时可达，长程还要解决工作如何跨会话继续。 我希望 LoopX 能把这份连续性提供给不同的 Agent runtime，让人的目标和判断少在交接中丢失。

欢迎大家拿真实问题来挑战这个设计，也欢迎参与代码、前端/飞书体验、故障恢复与测试。不会写核心代码也没关系：一个可复现的反例，往往比多加一个抽象更有帮助。

可以直接回复：你在哪个场景遇到问题？你希望接收方保留什么？你愿意参与哪一块？

感谢已经在管家、显式接续、状态事务与前端/IM 上投入工作的贡献者。我们沿着已有成果继续做，不要求大家从头再来。