Polymarket API 机器人需要明确回答一个棘手的操作问题：如果发出了订单，却始终没有收到可用响应，应当怎么办？订单可能被拒绝、被接受、部分执行或全部完成。本地超时无法区分这些可能性。
针对这种不确定性进行设计，会改变系统架构。机器人需要在传输之前建立持久记录，对新增风险敞口拥有受限权限，并有一个调查原始意图的恢复流程。它还需要在停止创建新订单之后继续观察账户。暂停决策与失去可见性，是不同的行动。
本指南描述适用于 Polymarket International 环境的教学设计。Polymarket US 有独立的账户和场所接口。这里所有限额、数量、价格和故障情景都是虚构例子。这种设计不能证明交易策略具有优势，也不授权任何真实账户操作。
定义有边界的 Polymarket API 机器人
有边界的 Polymarket API 机器人具有明确权限限制：可以使用哪个账户、考虑哪些合约、创建哪些订单类型，以及增加多少风险敞口。这些限制应能在预测组件之外强制执行，避免错误信号简单地自行宣布豁免。
一个虚构机器人可以观察研究列表中的所有市场，却只为两份获批合约提出订单。它可能具有每个事件三十份的限额，以及独立的最大买入资金承诺。观察范围广，并不意味着拥有同等广泛的交易权限。
较早的Polymarket 机器人 API指南解释了能力与故障模式。设计机器人时应使用这一区分：数据访问、订单创建、取消和钱包操作，是独立能力。只有当功能的目的和授权边界清晰时，才应把它纳入程序。
将预测与执行器分开
预测组件应生成一份提案，包含合约、方向、期望数量、最高成本，以及推理的失效时间。它不应直接持有不受限制的签名权限。独立的决策关卡可以根据当前账户状态和操作限额核查提案。
即使一个人运营整个系统，这种分离也有用。它使程序行为可检查：提案解释为什么考虑交易，关卡解释是否允许。被拒绝的提案仍然是研究记录的一部分，却不创建订单。
执行器应只接受完整指定、已经授权的指令。它不应因为第一次尝试未成交，就自行增加数量或放宽价格。这些变化会改变经济决策，需要根据账户和策略的当前证据重新验证。
在多次尝试中保留同一个经济意图
经济意图描述期望的账户变化，传输尝试则描述一次传达指令的努力。混淆两者是重复操作的常见来源。超时之后的新请求，不应自动变成第二个独立买入相同数量的愿望。
为意图分配稳定的本地标识符，并记录获批条款。在已知关联时，把每个请求、响应、订单标识符和交易观察连接到这一意图。如果后续指令替代它，应明确记录关系，而不是覆盖旧历史。
Kalshi API 交易指南提供了另一个 API 环境中账户核对的对照。意图与尝试的一般区别可以迁移，但可用的查询和重复处理机制不同。机器人必须核实实际场所语义，而不是假定存在通用幂等功能。
先写入持久化意图日志
在行动能够到达场所之前，持久化意图日志就必须存在。否则，传输之后发生崩溃，可能留下没有本地解释的有效订单。对于这个特定故障窗口，收到响应后再持久化已经太晚。
记录账户、合约、买卖方向、数量、限价、有效期、策略版本、授权结果和预留容量。添加恢复所需的请求身份或已签名订单引用，但不在普通日志中暴露秘密。日志应支持在流程重启后读取历史。
日志条目不能证明订单已发送。分别保留已准备、传输开始和观察到响应等阶段。这些阶段帮助缩小不确定性，但无法消除网络边界上的所有歧义。在获得账户证据之前，诚实的恢复状态仍可能是未知。
以原子操作预留容量
两份提案可以几乎同时到达，并都看到同样的表面可用预算。如果在任何预留记录写入之前分别批准，合并风险敞口就可能超过限额。账户关卡需要一个一致的操作，同时检查并预留容量。
假设虚构事件限额为三十份。账户持有十二份，现有有效订单还可增加八份。只有额外十份符合限额。如果两个新提案各请求十份，并且都读取同一个旧快照，同时批准就会允许合计四十份。
共享预留记录可以防止这种竞态。第二份提案必须看到第一份预留，或等待其结果确定。使用同一账户和事件限额时，独立工作进程、策略或用户界面不会创造独立的经济容量。
在不确定期间保留预留容量
状态未知的提交仍然可能变成风险敞口。仅因本地请求超时就释放预留，会让另一个提案使用同一容量。应保留保守的资金承诺，直到原始意图解决，或有记录的政策确立安全替代方案。
在三十份例子中，状态不确定的十份提交占用了新增入场的剩余容量。机器人可以继续读取市场数据、核对账户，并处理政策允许的降低风险操作。不应仅为保持活跃，就把未知数量视为零。
运营者应能看见这种行为。例如“十份已预留，等待提交核对”的清晰状态，可以解释为什么新提案暂停。如果没有解释，运营者可能重启机器人或移除预留，无意中破坏原本保护账户的控制。
使用当前账户和钱包设置
机器人必须核实当前签名者、账户钱包、权限和交易批准，才能执行。旧例子可能假定不同的钱包安排或客户端接口。成功访问公开数据，并不能验证私有交易路径。
Polymarket 的钱包与身份验证文档是账户专属设置的当前参考。把秘密材料保存在获授权的签名环境中，与普通应用日志和研究记录分开。恢复应依赖标识符和账户证据，而不是为了调试失败请求而暴露凭证。
把客户端版本和配置与操作记录一同存储。如果升级改变请求构造或响应解释，机器人应在恢复权限之前通过相关恢复案例。兼容性是需要验证的行为，不是熟悉的软件包名称所暗示的属性。
诊断故障发生的位置
失败工作流程可能在授权之前、传输之前、传输之后或核对期间停止。这些位置具有不同含义。本地被拒绝的提案不会创建订单。传输从未开始的请求，可能可以在同一意图下安全重试。远端结果未知的请求需要调查。
记录足够的时间和状态信息，以区分这些情况，但不要假装知道超出证据支持范围的内容。操作日志可以说客户端在某个时间开始发送，随后连接中断。它不能仅凭这个本地错误就认定场所从未收到字节。
使用能够引导具体行动的错误分类。身份验证失败应触发凭证或账户审查。价格增量无效应触发市场约束审查。提交状态未知应触发账户核对。笼统地重试所有错误，会忽视修正请求与意外重复有效请求之间的区别。
通过订单与交易证据调查
恢复状态未知的提交时，应使用场所支持的标识符和接口，寻找与原始意图有关的证据。当前未成交订单、单笔订单记录和账户交易，可以回答问题的不同部分。某一个列表缺少条目，并不总足以证明没有执行发生。
Polymarket 的订单管理指南描述了用于跟踪订单和账户交易的身份验证读取。机器人应将相关证据与持久日志结合。它还应保留查询时间和任何覆盖限制，例如分页不完整或数据流断开。
状态确定后，同时更新预留和头寸记录。有效订单保留适当承诺。确认拒绝可以释放它。执行会改变持仓和成本。如果证据仍然矛盾，应保持不确定性明确可见，并把案例交给负责的运营者。
推荐用户，赚取 USDC
推荐用户，赚取 USDC我们的联盟推广计划实时支付佣金。
不要从空的未成交订单列表推断拒绝
已经全部成交的订单，可能不再出现在未成交订单中。一张未成交数量已被取消的即时订单，也可能不留下挂单条目。因此，只看未成交订单列表，可能把全部或部分执行误判为从未存在的请求。
在认定原始意图没有影响之前，机器人必须检查其他相关记录。提交时可以立即成交的请求尤其需要这样做。有效剩余订单消失，并不意味着没有买到份额。
有用的运营者视图会区分三个问题：订单是否仍有效、是否发生任何交易，以及由此产生的账户变化是否已经核对。区分这些问题，可以防止把视觉上空白的订单面板当作账户已经没有头寸的证明。
正确核对即时部分成交
订单类型决定未成交数量的去向。当前 Polymarket 文档将 FAK 定义为成交可用数量，并取消剩余数量。部分 FAK 执行会留下头寸，但不会把请求中剩余份额留在订单簿上。
在一个虚构案例中，十份 FAK 请求有四份按 $0.43 执行、六份取消。费用前买入价格合计为 $1.72。在执行与剩余数量状态确定后，机器人应依据实际账户证据记录四份，并释放另外六份关联的预留。
十份挂单中四份已执行、六份仍有效，则是不同情况。它仍然保留未来可能的风险敞口。机器人的状态模型不应使用一种笼统的部分完成状态，替代已执行数量以及剩余数量最终结束或继续有效的状态。
处理取消竞态
取消请求可能与成交重叠。机器人应准备核对两者，而不是假定取消意图立即移除了风险敞口。成功取消可能只适用于额外执行已经发生之后的剩余数量。
假设取消开始时显示六份仍有效，而在其余部分移除之前又执行了两份。机器人必须把这两份加入头寸，并只释放实际结束的承诺。替换提案应使用由此产生的账户状态，而不是竞态之前可见的数量。
较早的Polymarket 自动交易机器人指南讨论了暂停和重启行为。取消只是这一流程的一个组成部分，不是通用重置。停止新决策、撤回可以取消的订单，以及核对现有头寸，是可能在不同时间完成的独立责任。
使用唯一的权威提交路径
多个工作进程可以帮助收集数据或评估独立假设，但订单提交需要协调权限。如果两个执行器能够在没有共享认领机制的情况下处理同一意图，二者就可能在重启或消息延迟后都将其传输。
为活跃执行器选择明确的归属规则，并让归属变化可见。新工作进程不应仅因心跳延迟，就假定旧工作进程已经停止。它需要一种机制，防止两者并发使用同一权限，或使用在归属确定前暂停的政策。
目的不是为复杂而复杂。单进程机器人可以采用简单设计，只要重启行为明确。随着系统扩大，应保留相同的经济保证：一个获批意图不应因为多个组件都认为自己负责完成它，就变成多张独立订单。
重启后先重建，再恢复
重启应从观察和核对开始。加载未解决意图，检查当前订单和交易，验证账户身份，并将恢复的持仓与本地记录比较。在相关差异解决或按操作政策明确处理之前，应等待而不新增风险敞口。
不要把每个未完成日志条目都作为新订单重放。有些未完成条目可能对应远端已经执行、但响应丢失的操作。另一些可能从未离开进程。恢复路径必须依据证据分类，而不是把缺少本地完成标记当作再次传输的许可。
Kalshi API 机器人指南描述了另一个场所的验收案例。利用这种对照明确恢复问题，同时保持场所专属标识符和请求行为彼此独立。同一个故障情景在不同接口中可能需要不同查询。
决策暂停时保持观察活跃
暂停新增入场的机器人，通常应继续执行理解账户所需的读取操作。关闭所有组件会使不确定状态更难解决，也让运营者失去有效订单或头寸的当前信息。
按照能力定义操作模式。仅观察模式可以刷新市场和账户数据。核对模式可以调查先前行动。取消模式如果获得授权，可以允许特定降低风险操作。交易模式可以在限额内创建新风险敞口。
每种模式都应具有明确进入和退出条件。如果还有未解决意图，网络恢复本身不应自动恢复交易。反过来，研究来源故障也不必阻止通过健康的私有接口核对账户。细粒度能力边界，帮助机器人在不超越权限的前提下保持有用。
让运营者消息可以指导行动
运营者应收到未解决状态的简洁解释：账户、合约、原始意图、可能风险敞口、最后核实的证据，以及下一步调查行动。只有堆栈跟踪，无法解释故障的经济后果。
避免在没有背景时要求运营者在重试与忽略之间选择。可用行动可能包括查询原始订单、检查账户交易、继续暂停，或升级处理矛盾记录。机器人应在日志中保留每项行动的影响。
平台审查有助于组织这一界面。Polymarket 交易平台指南区分了账户控制、价格形成和结算。这些区别在故障期间仍应可见，因为此时读者尤其容易把正常工作的市场数据屏幕，与已经完整核对的交易账户混淆。
测试网络边界处的故障
有用的验收演练会在多个点中断流程：意图持久化之后、传输期间、远端接受之后但本地响应存储之前，以及成交到达之后但头寸视图更新之前。每次中断都应导向可恢复或明确未解决的状态。
预期结果并不总是自动继续。有些案例应以暂停结束，因为可用证据无法安全确立账户状态。测试应验证机器人保留预留、避免重复风险敞口，并向运营者提供足够调查信息。
在重放中纳入重复和延迟消息。重新处理已知交易不应把数量加入两次。迟到的拒绝应关联正确请求，而不是覆盖另一项成功意图。与在理想条件下反复提交普通订单相比，这些案例更有意义地测试记录模型。
审查机器人的经济记录
操作指标应包括未解决意图的持续时间、核对延迟、重复观察和预留差异。仅看请求成功率，可能显得健康，账户记录却是错误的。少量不确定提交可能比数千次成功的公开读取更重要。
较早的预测市场机器人 API指南提供了更广泛的架构视角。在边界处审查机器人：进入了什么证据、授予了什么权限、发出了什么指令，以及返回了什么账户状态。这些边界能够指出故障在哪里改变了含义或超出范围。
把策略评估分开。机器人可以忠实执行糟糕策略，而有前景的预测也可能被不可靠执行破坏。经济日志让这两个问题都能得到检查，而不必把每个结果都归因于最显眼的组件或最新错误消息。
让 Polymarket API 机器人不超出证据范围
边界清晰的机器人知道何时有足够证据行动，以及何时只有足够证据调查。其持久日志把一个意图连接到相关尝试、订单和交易。其预留会计入可能风险敞口，直到不确定性解决。
从范围较窄的权限集合和完整恢复方案开始。根据当前文档核实账户设置，协调提交权限，并在扩大范围之前测试中断。让暂停可以解释，并保持解决暂停所需的观察可用。
结果是一种无论正常运行还是故障时，行为都可以重建的程序。它不会把不确定预测变成确定结果。它确实让操作主张变得精确：机器人应只执行自己获授权尝试的有限行动，然后先确定实际发生了什么，再把账户视为可以进行下一次决策。