Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

A coworker created as Built in still cannot hand work on

未關閉
  • 哪裡不對？
#399 3 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

  • #695 來自 @Harbor404 —— 已關閉，未合併

評估

難度
5/5
預估耗時
一週以上
新手友好度
25/100
Issue 類型
功能
描述清晰度
需要釐清
活躍度
活躍
技術堆疊
typescript
領域
backend-api-design

研究方向

閱讀 #317 中延後的設計以及 #331 中描述的行為，然後檢查 plugins/store.ts，尤其是 agentRunsHere 和 managedConfiguration 路徑。比較無 endpoint 的 built_in 儲存選項與在 callback surface 上 mint 一個 hop endpoint，並記錄對於已有 managed Bot 的部署以及已經儲存為 remote_ag_ui 的同事所選擇的行為。

由索引模型根據 Issue 內容生成。

描述

Tracking the design question #317 deferred on purpose, so it survives the PR that half-answers it.

From that PR's description:

A coworker created as "Built in" through the wizard is stored as remote_ag_ui pointed at the
managed endpoint. Its tool callbacks work (the deployment-token path), but the handoff tool is
minted only inside this deployment's own run loop, so such a coworker can be asked but cannot
itself hand work on. […] Fixing it properly means either storing endpoint-less creates as
built_in type, or adding a server-minted hop endpoint to the callback surface — worth its own PR
either way.

What #331 covers

#331 takes the first option, because the interview it adds cannot end by asking somebody for a URL.
store.create writes a built_in coworker running on its role description where there is neither
an endpoint nor a managed Bot — which on the one-container image the README recommends is every
coworker.

That buys back exactly what the note was about, in that case: agentRunsHere is
row.type === "built_in" (plugins/store.ts), and grantable on the handoff answer comes from it,
so a coworker created that way can be handed work on.

What is still open

Where the deployment does have a managed Bot, create still prefers managedConfiguration, the
row is still remote_ag_ui, and nothing changes: the coworker can be asked and cannot hand work on.
The wizard's "Built in" option is only offered on exactly those deployments, so the case #317
described is the case still outstanding.

Two ways out, both from the original note:

  1. Store endpoint-less creates as built_in even when a managed Bot exists. Smallest diff, and
    it makes "Built in" mean one thing everywhere rather than two things depending on configuration.
    The question is what happens to coworkers already stored the other way — they keep working, but
    the roster then holds both shapes with no way to tell them apart except the endpoint string.
  2. Mint a hop endpoint on the callback surface. Leaves storage alone and makes the handoff tool
    reachable from outside the run loop. Larger, and it puts a new server-minted address into a
    surface that currently only issues tokens.

Not proposing either — this is #317's question and the choice is its author's. Filing it so it does
not disappear when #331 merges and the no-managed-Bot half stops being visible.

主要語言
TypeScript
星號
6.6k
分支
914
平均合併
19 小時 22 分鐘
30 天內合併 PR
140

環境準備

  • 提供 Dockerfile 或 Docker Compose 檔案
  • 有 Pull Request 範本
  • 沒有貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

CopilotKit/OpenBot 的其他 Issue

查看 CopilotKit/OpenBot 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。