事件合约机器人：从数据到对账

事件合约机器人需要合约注册表

首先建立机器人可考虑合约的明确注册表。存储场所背景、市场标识符、结果标识符、结算单位和规则引用。加入事件时间、交易截止和合约指定来源。注册表应区分首次发布和修订值，并保留每次决定所用映射版本。

这比只有市场标题的搜索结果更精确。自动搜索可以发现候选合约，但发现不应悄悄授权交易。两个市场可以标题相同，却阈值或观察窗口不同。人工审查映射或经过测试的规则匹配，必须确认机器人数据回答的是合约结算问题。

将映射变化视为重要系统事件。如果之前识别字段不可用，不应仅为流程继续就选择同名近似字段。如果出现合约澄清，保留旧解释，并记录新信息审查。这段历史对理解较早仓位为何在之后可能改变的假设下建立很必要。

较早的预测市场机器人 API 指南帮助识别合约标识符与账户操作的联系。注册表不只是编程便利，而是防止一个事件信号被路由到表面相似、经济上不同仓位的边界。

将观察与解释分开

观察层记录来源报告什么，以及系统何时收到，不应立即将每项更新变交易信号。保留来源时间戳、接收时间戳、标识符和准确相关值。消息重复时标为同一观察，而不是第二次独立确认。乱序时保留排序信息，不用旧观察覆盖新观察。

解释层决定观察对合约意味着什么。报告指数等于 100.3，可能支持高于 100.2 阈值的 Yes，但前提是正确发布、字段和舍入。标题说指数好于预期，不足以回答绝对值合约。解析器必须提取合约相关事实，而非一般正负情绪。

有些输入支持概率估计，而非直接事实判定。程序应将输出标为预测并保留不确定性。语言模型或分类器置信值，不自动是合约支付的校准概率。解释需要新法律或事实判断时，系统可送审，而不授予模型创造敞口的权限。

有用诊断视图将原始观察与派生断言并列。操作人员质疑决定时，应能检查联系，不必从价格图重建。这也使来源故障更易隔离：陈旧观察、提取错误和合理但失败预测，是需不同修复的问题。

定义事件合约机器人决策权限

建议阶段提出含合约、方向、数量、价格限制和原因的操作。授权阶段决定是否符合账户当前约束。即使小程序也应分开。策略可能建议买入，而账户已达事件限制、另订单未解决，或市场流过旧无法支持价格。

授权记录应明确检查的限制，可以包括最大获取成本、最大事件敞口、最大未完成订单数，以及合约映射保持当前。结果是带过期的有边界许可，不是无限重试直至获得所需数量。提交前条件变化，执行器应请求新决定或拒绝。

例如，虚构策略建议 100 个 Yes 单位，买价上限 $0.56，另预留 $2 收费。风险关卡允许此事件最多 $60 承诺。拟议最大承诺 $58，符合该项约束，却仍可能因同市场未解决订单或缺少官方来源时间戳等其他条件失败。

机器人承担多任务时，区别尤其重要。研究模块可以加合约到观察列表，不应仅因与执行器共享进程就获得交易许可。通知模块可以提醒异常价差，却不授权新策略。明确权限防止有用观察变意外账户指令。

发送任何操作前预留敞口

事件合约机器人敞口预留，防止多个同时决定花费同一容量。指令获授权时，在提交前预留最大允许成本和相关事件敞口。订单未完成或结果不确定时保留，仅释放权威记录确认不再能执行的部分。

假设虚构的 100 单位订单开始成交。四十个以 $0.54 执行，收费前成本 $21.60。六十个仍以 $0.56 限价挂着，潜在额外买入成本 $33.60。保留 $2 费用储备后，合计承诺 $57.20。已执行部分价格更低，使承诺从原始 $58 降低，但未成交仍可能成为未来仓位。

如果相关现金预算 $100，简化预留留下 $42.80 未承诺。不能仅因目前花了 $21.60 就说剩 $78.40，那会忽略未完成订单，让另一策略消耗潜在成交所需资金。真实实现也必须对账实际费用和平台特定预留行为。

同账户各策略应使用同一共享敞口视图。独立计数程序可能各自认为容量充足。较早的预测市场交易自动化讨论提供协调背景。无法确定其他指令是否仍可执行时，预留系统应保守处理。

将订单建模为状态，而不是成功消息

订单请求可以处于准备、已提交、已确认接受、挂单、部分成交、完成、拒绝、取消或不确定。这些是概念状态，不声称每个 API 都用准确同名。将实际响应映射到有记录本地模型，并保留原始响应供之后调查适配器错误。

网络响应成功，可能确立请求已接受，却不证明数量成交。反过来，网络超时也可能发生在场所已接受后。机器人必须避免将每次成功视为完成仓位、每次超时视为拒绝。订单标识符、成交记录和账户快照提供不同证据。

当前Polymarket 订单生命周期文档区分订单与交易状态，说明一个名为完成的本地布尔值不够。实现必须遵循具体场所和产品状态，包括报告匹配后仍未解决的中间执行或结算状态。

执行器也应保留原始获授权指令。订单以更优价成交，结果仓位仍应追溯同一许可。剩余数量需要更高价，则是需按策略新授权的决定。悄悄提高限价补足目标，会将受控执行器变成未经审查策略组件。

事件合约机器人恢复状态防止重复敞口

设想提交响应从未到达。本地知道已发送尝试，却不知道是否变成订单。正确下一状态是不确定。保留敞口预留，并用场所支持标识符和账户记录调查。不要仅因首次响应缺失就创建新订单。

假设原指令请求 100 个单位。之后账户记录显示 40 已成交、60 仍开放。机器人请求取消余量，但生效前又成交 15。已对账仓位为 55，取消确认后另有 45 不再开放。如果假设原尝试失败，再发一笔 100 单位订单，就可能严重超预期敞口。

恢复应在重启后持久。按系统一致性设计，在受控提交之前或过程中写尝试标识符和预留。重启时，在接受同敞口新建议前检查未解决尝试。干净程序启动不意味着账户干净，场所仍可能持有上个进程创建的订单。

事件合约自动化指南将区别扩展至周边研究和审查。恢复不只是罕见停机工程细节，而是策略敞口控制一部分，因为本地断开、重启或等待响应期间账户可能改变。

建立独立于策略的对账循环

对账将本地预期与权威账户记录比较，即使无新信号也应运行。用一致标识符和观察时间比较未完成订单、执行数量、仓位、收费和可用余额。不匹配应产生明确异常，而不是悄悄更正并抹除本地模型为何出错的历史。

区分普通时间差与无解释差异。根据场所报告路径，成交更新可能早于余额更新。系统可以在等待一致快照时允许文档临时状态。但差异持续超出预期流程，应阻止受影响范围的新敞口，直到解释；范围可以是一个市场、账户或整个执行器。

对账记录应说明哪些观察支持当前仓位。操作人员应能看到 55 单位来自 40 和 15 两次成交，而不是舍入余额推断差值。单独保留费用调整，防止现金变化被误认为合约数量变化。判定后，将支付连接实际剩余仓位和最终合约结果。

使用账户接口构建的读者，可以用较早的Kalshi API 交易机器人讨论组织记录。原则独立于实现语言：策略提议应该发生什么，对账确立实际发生什么。两者都不应以自身预期替代缺失证据。

为多腿和报价系统增加边界

方向性机器人通常可用一个仓位表达敞口。多腿系统需要跟踪组合是否完整，以及只部分订单执行时剩什么。候选事件合约套利依赖兼容支付和可行执行。机器人应表示每腿及合计可能结果，而不是首次订单接受就将配对记完成。

为未完成腿预留容量，并定义可保持未配对的最长时间或条件。第二腿不可用时，系统需要与账户损失限制一致的预定义响应，例如取消未成交订单、减少第一仓位，或保留有边界敞口待审。不应假设任何价格的对冲都自动优于有序决定。

报价系统挑战不同：两侧可以仍有效，成交却改变库存。事件合约做市商因此需要考虑库存的权限和可靠未完成报价视图。替换旧订单的报价更新，必须考虑两条指令可能同时有效的间隔。允许毛敞口和净敞口应反映可能性。

这些扩展说明，通用买卖函数不是完整架构。不同策略需要不同表示不完整工作的方式。共同基础是明确权限、保留订单身份和对账；策略特定层描述哪些成交组合可接受，以及下一操作前需要什么证据。

跟踪管理决定的时钟

机器人应保留多个时钟，因为回答不同问题。事件来源时间戳描述信息何时发布，接收时间戳描述本地何时获取，订单簿时间戳描述建议使用的市场状态，授权时间戳描述账户何时批准。合为一个时间字段，可能把陈旧观察藏在新处理事件后。

假设观察 9:00 发布、9:01 到收集器、重启后 9:10 重放。对重启进程是新输入，但底层证据已十分钟旧。只按本地插入时间的新鲜度规则，可能允许将其视为当前。保留原始时间并明确标记重放，使规则评估本来要约束的事实。

时钟比较也需要缺失或不一致值策略。来源没有可信发布时间，系统不应虚构。可以采用带更紧权限的文档后备，或暂缓需更强时间证据的操作。目标是让时间不确定性在记录中可见，而不是精确时间戳暗示系统不具备的知识。

用会改变账户的事件测试

有用测试聚焦重要转换。模拟接受后响应超时、取消期间部分成交、市场快照陈旧和带未解决订单重启。验证机器人保留正确预留，并拒绝可能超限操作。只确认函数返回内部赋值的测试，对真实故障路径证据很少。

使用少量已知预期记录的可重放事件。100 单位示例应结束为 55 已成交、45 已取消，没有第二次 100 单位提交。现金模型反映实际成交价格和收费，而非原始最高估计。另一测试可故意漏成交事件，要求对账从账户查询恢复执行。

也测试无害不活动。预测不可用、映射未解决或账户状态不一致时，正确结果可能是不下单。只评估成功提交的系统，可能奖励活动，却忽略防止非预期敞口的决定。记录拒绝原因，让操作人员区分有意暂停与未注意故障。

只有记录让正常运行与恢复都可理解时，才适合更广用途。操作人员应无需猜测就识别当前合约、证据、许可、未完成承诺和已确认仓位。这种透明不证明交易优势，却使程序行为可审查，并为评估策略提供可靠基础。