fix(acp): instruct model to treat ACP attached-file blocks as inline context - #57509
fix(acp): instruct model to treat ACP attached-file blocks as inline context#57509NakePranob wants to merge 1 commit into
Conversation
…context The ACP adapter inlines user-attached files as: [Attached file: <name>] URI: <path> <file content> Models treat this as plain text rather than real file context and often try to shell-fetch the file instead of reading the body already present in the prompt. Add a short instruction in the stable system-prompt tier so the model uses the inline content directly.
Related: #25611 (ACP embedded_context / resource-block extraction), #57510 (companion adapter compliance PR from the same author). This is the genuine one-line prompt tweak (unlike the closed #56742, which carried a full adapter overhaul under a similar title). |
|
Thanks for splitting this into a focused ACP change. The underlying attachment format is present on current main: Problems
Suggested changes
This is an automated hermes-sweeper review. |
GottZ
left a comment
There was a problem hiding this comment.
This was generated by AI during triage.
Summary
Two PRs address the ACP attached-file behavior: #56742 combines the prompt hint with a broad ACP/CLI overhaul, while #57509 isolates the prompt change intended to make models consume inline attachment content. The focused diff in #57509 targets the reported model behavior, but its unconditional wording does not match the adapter’s link-only, omitted, failed-read, and truncated attachment cases.
Related pull requests
- #56742 [closed]
related— (+1024/-64) — superseded: This closed PR includes the same system-prompt hint as #57509 but also mixes in extensive ACP capability, resource-handling, plan-update, skill, CLI, test, and artifact changes; it remains relevant as the oversized source change that was split after contributor feedback into focused PRs including #57509. - #57509
related— (+7/-0) — keep open for revision: The focused system-prompt addition directly targets redundant tool fetching, but the contributor keep_open review correctly notes that the hint currently affects every platform and falsely treats every[Attached file: ...]block as complete inline content, despite link-only, omitted, read-error, and truncation paths in the adapter.
Duplicates
#57509 duplicates the system-prompt portion of closed #56742; #56742 is not a full duplicate because it also contains the broader ACP adapter and CLI changes later split into separate PRs.
Suggested consolidation
Revise #57509 rather than merge it as-is: scope the hint to ACP, instruct the model to use the inline body only when present while preserving fallback behavior for link-only, omitted, failed-read, and truncated content, and add ACP-only prompt-builder coverage. After those changes address the contributor keep_open review, merge #57509 as the focused fix; #56742 can remain closed as superseded.
Cross-PR triage: Reviewed 2 pull requests and 0 issues in this complex. Each diff was read against this issue; Assessment working set: 70 kB of PR diffs, 2 kB of issue/PR text, 3 kB of discussion (5 comments), 0 verify verdicts. verdicts reflect diff content, not PR titles. Part of an automated triage batch.
|
ปิด PR นี้ตามคำขอ (no longer needed / cleanup) |
Description
When the ACP adapter (Zed editor) sends
@-tagged files to the model, the file content is inlined as[Attached file: <name>]text blocks. Without explicit instruction, LLMs treat these blocks as ordinary text and may attempt to fetch the file via tools instead of reading the content already present in the conversation.This PR adds a one-line instruction to the agent's system prompt telling the model to read
[Attached file: ...]blocks directly as file context.Changes
agent/system_prompt.py— add instruction for ACP attached-file blocks1 file, +7 lines.
Related issues
embedded_contextcapability and extract text from resource blocks #25611 — The adapter now properly advertisesembedded_contextand extracts resource blocks, but the model also needs an explicit system-prompt instruction to treat[Attached file: ...]blocks as inline content rather than attempting tool-based fetches.