开发系统最极致高效的Agents.md，没有之一： AGENTS.md 核心原则 - 选择最简单的实现方式，完全满足当前需求。避免不必要的抽象、配置、间接性或投机性的扩展性。 - 做出最小必要的更改以解决根本原因。不要重构无关模块或更改策略语义，除非明确要求。 - 分层扩展系统。从最小的端到端工作版本开始，逐步增加新功能。绝不要用未完成的复杂性替换一个正在工作的系统。 - 优先重用现有项目组件，而不是创建新的组件。更倾向于扩展经过验证的模块，而不是引入平行实现。 - 优先选择维护良好的库，当它们能减少整体复杂性或提高可靠性时。不要在没有明确收益的情况下重新实现常见功能。 - 保持组件模块化，并明确定义职责。避免策略逻辑、执行、会计、回放和基础设施之间不必要的耦合。 - 一旦功能或策略被验证，设计应考虑长期可维护性。在没有证据支持之前，不要过度设计投机性想法。 --- 策略开发 - 在引入仅向前逻辑之前，尽可能通过历史回放验证假设。 - 每个交易策略必须经历回放 → 影子 → 金丝雀 → 实时阶段。不要跳过验证阶段。 - 基于可测量的证据做设计决策，而不是直觉。只有在证明存在优势后才进行优化。 - 将每个策略视为独立的合同。未经明确授权，不得静默更改冻结行为。 --- 现有系统 - 不要因无关工作破坏正在运行的影子或实时系统。 - 仅在主动生产或验证工作流需要时保留兼容性。否则，移除过时代码，而不是积累兼容性层。 - 尽可能重用现有基础设施，包括回放引擎、会计、执行、钱包管理、订单簿处理、日志记录、监控和守护进程框架。 --- 工程标准 - 优先选择确定性行为，而不是隐藏的自动化。 - 当假设被违反时，应大声失败。不要静默忽略错误或回退到意外行为。 - 保持配置最小化。只有在行为确实需要变化时才引入新配置。 - 移除无用代码，而不是留下未使用的路径。 - 编写易于检查、回放、测试和推理的代码。 - 除非明确要求进行架构更改，否则实现应与现有项目架构保持一致。 --- 范围纪律 - 仅实现请求的范围。 - 不要引入无关的优化、重新设计、迁移或功能扩展。 - 对于请求范围之外的非阻塞发现，可以单独记录，但不得合并到当前任务中。 - 一旦满足商定的验收标准，即视任务完成。后续改进应作为单独的工作项处理。