技能介绍

解决什么问题

当你需要为终端用户账户在 Alpaca 上执行交易时，标准 Trading API 只能操作自己的账户。Broker API 的关键差异是 account_id 出现在请求路径中：你代表用户账户操作，而非自己。这带来几个实际问题：如何在多账户场景下管理订单生命周期、避免重复下单、正确处理分数股和名义金额订单的边界条件。

核心能力

该技能围绕 Broker API 的订单端点展开：

订单管理：POST /v1/trading/accounts/{account_id}/orders 创建订单，PATCH 修改，DELETE 撤销单个（204）或全部（207 Multi-Status）
订单类型：market、limit、stop、stop_limit、trailing_stop；TIF 支持 day、gtc、opg、cls、ioc、fok
数量规则：qty 与 notional 互斥，同时传入返回 400；两者均为 decimal string，最多 9 位小数
分数股与名义金额：默认开启，要求资产 fractionable: true；TIF 必须为 day；notional 仅限 market/limit（day），且不可 replace
查询：按 client_order_id 查询、按状态/标的过滤列表、读取持仓与账户购买力

订单状态与陷阱

终态为 filled、canceled、expired、rejected，其余均为进行中。注意订单状态与 trade events 不同：SSE 流中有 held 事件，但不存在 held 状态。

常见坑：

Wash-trade 拒绝（403）：同账户反向自相交订单会被拒；bracket/oco/trailing_stop 组合单豁免
Bracket 约束：父单必须同时带 take_profit.limit_price 与 stop_loss.stop_price，买入时 TP 必须高于 SL，子单在父单完全成交后才激活
Replace 不保证成功：PATCH 返回 200 后若原单先成交仍可能被拒，需监听 trade events 流
PDT 字段已废弃：daytrade_count、pattern_day_trader 等自 2026-04-27 起废弃，不要依赖

幂等与循环投资

始终设置 client_order_id 作为去重键，并配合本地「已提交」标记防止重复下单。循环投资的稳健流程：取待执行指令 → 检查 buying_power/cash → 下名义金额单 → 记录订单 → 创建成功后才标记指令完成。余额不足时撤销指令并通知用户，而不是静默跳过。成交跟踪走 SSE trade-updates 流，不要轮询单个订单。