用以下Agents.md可以缓解GPT-5.6 Sol的过度设计和测试。我在做一个更细致但更重的方案，做好之后发出来。 ## Design simplicity (anti-over-engineering) Over-engineering is the most frequent correction in this workspace. These are hard defaults and they apply INSIDE the requested scope, not just to adjacent changes: - No backward compatibility, migration shims, legacy fallbacks, or old-data backfill unless the user explicitly asks for them. Assume breaking changes are acceptable by default. - Words like 完美 / 长远 / 通用 / 一定不能影响 / "perfect" / "long-term" describe quality goals, not authorization to platformize. Implement only what the current stated requirement needs; mention future extensions as one-line notes in the final message, never as extra code, schemas, tiers, modes, or config surfaces. - Do not mechanize judgment: no hardcoded validators, closed error-code sets, alias tables, or rule engines to enforce what instructions and review already cover. - Validate once at the trusted boundary. Do not duplicate the same check across layers (double probes, dual bookkeeping that must be reconciled). - Design-size checkpoint: before writing code, if the plan adds a new abstraction layer, a new config surface, more than ~5 new files, or any speculative option, present the minimal version and the additions as separate items and default to the minimal version. - VibeGuard's error-handling strictness (U-17/U-29) applies to real error paths inside the requested change; it never justifies adding new validators, checks, or compatibility layers. - When the user says something is over-designed: cut it, do not defend it. ## Problem framing and tool choice - Before the first tool call, identify the exact target, failure direction,and requested access path. - The user's latest correction overrides earlier assumptions immediately. - When the user specifies SSH, CLI, API, or another access path, use that path. Do not substitute UI automation unless the requested path is unavailable. - Do not use Computer Use, desktop UI automation, screen control, or synthetic clicks/keystrokes unless the user explicitly requests Computer Use or UI operation for the current task. The presence of a running desktop app, an available Computer Use tool, or a potentially useful signed-in session is not authorization. - Diagnose the named system first. Do not inspect or modify adjacent tools merely because they could plausibly cause the symptom. - For troubleshooting, establish evidence before mutation. Make one minimal change, verify the original symptom, then stop when it passes. - If the target or direction is genuinely ambiguous, ask one short clarification question before operating external systems.