fix(runtime): apply agent custom system prompt on the web chat path#445
Closed
LikiosSedo wants to merge 1 commit into
Closed
fix(runtime): apply agent custom system prompt on the web chat path#445LikiosSedo wants to merge 1 commit into
LikiosSedo wants to merge 1 commit into
Conversation
chat.send only read params.systemPrompt when building the box prompt. sicore's web-chat proxy never forwards that param, so a custom-prompt agent silently fell back to AgentBox's built-in default SRE persona on sicore web chat — while channel paths (dingtalk/lark) resolved the agent's own template and worked. Root-cause chain: - sicore sends chat.send without systemPrompt (proxy/handler.go). - runtime chat.send only honored params.systemPrompt -> undefined -> box uses the default template. - resolveAgentSystemPrompt (config.getAgent -> agents.system_prompt) already existed but was wired only into dingtalk/lark/task-coordinator/ delegate paths, not the web chat main path. Fix (runtime-side fallback, sicore unchanged): when the caller does not forward systemPrompt, chat.send falls back to resolveAgentSystemPrompt. An explicitly forwarded prompt (portal-standalone) still wins as-is; a resolve failure / no custom prompt falls back to undefined = built-in default, so a lookup failure never turns a chat into a failure. Session-reuse semantics unchanged: AgentBox applies the template only at session creation, so this affects NEW sessions; a warm multi-turn session keeps the prompt it was created with. chat.send is the only prompt- creating entry point (chat.steer targets an already-running session via steerSession), so no other handler needs the fallback. Adds server-chat-system-prompt.test.ts covering: explicit param wins and skips the lookup; omitted param resolves the agent's custom prompt; no custom prompt / lookup failure -> undefined default (send still acks ok).
Collaborator
Author
|
Consolidated into #446 per owner request; review history stays here. This PR will be closed once the batch merges. |
Collaborator
Author
|
Superseded by #446 (platform hardening batch); branch retained. |
pull Bot
pushed a commit
to TheTechOddBug/siclaw
that referenced
this pull request
Jul 23, 2026
Apply agent custom system prompt fallback on the web chat path (gateway chat.send).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
A custom agent's
system_promptwas silently dropped on the sicore web chat path: in the browser the agent introduced itself with the default SRE persona and ignored the custom prompt's rules. The same agent worked over Feishu/DingTalk.Root cause (confirmed)
chat.sendwithout asystemPromptparam (proxy/handler.go).chat.sendhandler only honoredparams.systemPrompt(src/gateway/server.ts) → absent →undefined→ AgentBox falls back to its built-in default SRE template.resolveAgentSystemPrompt(agentId, frontendClient)(config.getAgent→agents.system_prompt) already existed, but was wired only into the channel / coordinator / delegate paths (dingtalk.ts,lark.ts,task-coordinator.ts,delegate-api.ts) — not the web chat main path.So: sicore doesn't send it → the runtime only read the param → the channel paths had already resolved it while the web path never did.
Fix (runtime-side fallback, sicore unchanged)
In
chat.send, when the caller does not forwardsystemPrompt, fall back toresolveAgentSystemPrompt(agentId, frontendClient):resolveAgentSystemPromptswallows RPC errors and returnsundefinedon failure / no custom prompt → built-in default. A lookup failure therefore never turns into a chat failure (the send still acksok).Session-reuse semantics
AgentBox applies the template only at session creation, so this affects new sessions; a warm multi-turn session keeps the prompt it was created with — matching the existing channel-path behavior. No hot-update is introduced.
chat.sendis the only prompt-creating entry point inserver.ts;chat.steertargets an already-running session viasteerSession, so no other handler needs the fallback.Tests
src/gateway/server-chat-system-prompt.test.ts(drives the realchat.sendhandler fromstartRuntime):systemPromptparam wins as-is and skipsconfig.getAgent;system_prompt: null) →undefined(built-in default);config.getAgentthrows →undefineddefault, and the send still returns{ ok: true }.tsc --noEmitclean; fullsrc/gatewaysuite green (993 tests).