给 Agent 设置一条成本边界

一个模型接口接通之后，最容易先观察到的是答案质量和等待时间。成本常常要等到请求持续出现，才从配置页面里的一个数字变成实际约束。免登录开放的入口尤其如此：访客不需要注册，系统却仍然需要为每次调用承担工作。

成本控制不适合等到功能完成后再补一层限制。它会影响用户能问多少次、一次回答有多长、失败怎样重试，也会影响服务端应该保存哪些状态。

从一次调用的组成开始

一次问答发送的不只是最后一句问题，还可能包括历史对话、系统说明和检索资料。回答变得更详细，也会增加输出量。因此，同样一次“提问”，背后的工作可能相差很大。

在增加上下文之前，可以先问它是否帮助当前问题；在放宽输出长度之前，可以确认资料是否真的支持更多内容。只保留近期几轮历史、限制检索片段、为不同问题安排合适的回答深度，既改善阅读，也减少无关信息的传递。

这些约束应该有具体目的。过度缩短上下文会让追问失去主题，过度压缩回答又可能使介绍类问题只剩一句口号。目标是把工作集中到当前任务，而不是一味追求最短。

次数额度说明的是使用机会

每位访客的每日额度，可以帮助限制重复调用；全站额度则为所有访客合计的工作设置一条总边界。两者需要同时存在，否则大量不同访客仍可能让一个单独的个人限额失去保护作用。

本站第一版选择每 IP 每日 5 次、全站每日 100 次。这是一种使用规则，不是对实际费用的精确计量。共用网络的访客还可能共用额度，因此界面应该说清楚它按什么条件计算。

请求次数也不能代替输入与输出限制。一段很长的历史和一句简短问题都可能只记为一次，但消耗的工作不同。额度与内容长度分别管理，规则才更接近实际运行。

失败也可能已经产生工作

没有得到完整答案，不代表模型调用完全没有发生。请求可能已经发送，服务也可能已经生成了部分内容，最后才因为断线或截断失败。是否扣除次数，需要在产品中做出明确选择，而不是根据有没有展示答案临时决定。

Field Agent 当前将失败请求计入额度，并在接口中返回剩余次数。用户会少一次提问机会，所以说明应当放在能找到的位置；重试也不应该被伪装成没有影响的动作。

对快速重复的请求，可以用短间隔限制减少误触。对于真正需要重试的失败，则保留输入，让用户能判断是否值得再次发起。控制频率与支持恢复，需要同时考虑。

给长期等待一个结束条件

超时、取消和最大输出限制，都为单次工作设置了结束条件。它们可以防止一个请求无限等待，也能让界面在无法完成时回到可操作状态。

生产计数还需要跨实例保存。若计数只放在某个进程中，重启或切换实例就可能失去累计结果。当前方案使用持久化的共享计数，本地开发则保留简单的进程内替代，两种保证应在文档中明确区分。

一个可持续的开放入口，最终需要回答四个问题：一次会做多少工作，谁可以使用多少次，失败留下什么，什么条件会让任务结束。把这些边界放进最初的设计，成本才会成为可以讨论和调整的产品条件。