外观

象信控制台
概念

状态

什么是状态（state），如何组织它，以及怎样给系统一模型恰好够用的上下文。

状态 ​

**状态（state）**是你请系统一模型评估的内容：一条客服消息、一段合同、一份简历，或者你应用程序此刻的某个状态。它放在请求的 state 字段里，和你想问的问题一起发送。

每个请求评估一份状态，可以附带一个或多个问题。所有问题看到的是同一份状态，但彼此独立地作答。Choice、Score、Noul 可以在同一个请求里混用。

字符串，或结构化的 JSON ​

最简单的状态就是一个字符串：

python
state = "快递显示已签收，但我根本没收到包裹。"

状态也可以是 JSON 对象或数组，里面装着相关的上下文、参考规则、历史记录等帮助模型作答的材料。可以把状态想象成：在请一组专家做判断之前，你摊在桌上的那叠材料。 在 Python 里，直接把字符串、字典或列表传给 client.system_one(state=...) 即可。

形式适合例子
字符串单条消息、一篇文章、一段文字"快递显示已签收，但我没收到。"
对象有名字的字段、关联记录、应用状态{"message": "快递显示已签收……", "order_id": "JD-8812"}
数组一串消息或记录["在吗", "我的会员号是 VIP2291", "快递显示已签收但我没收到"]

大多数情况下推荐用对象：每一部分都有一个说明性的名字，彼此的关系一目了然，问题也可以精确地指向其中某个字段。只有当场景简单、只需要一段文字时，才直接用字符串。

语言与格式

象信一号只接受文本：字符串、JSON 对象，或由文本构成的数组。中文和英文都能处理，也可以混排。无论哪种语言，都建议先用你自己的数据做评估，并关注置信度。

下面是一份完整的状态示例，包含对话、订单和规则：

json
{
  "ticket": {
    "subject": "包裹未收到",
    "messages": [
      {"from": "customer", "text": "快递显示昨天已签收，但我家里没人收到，驿站也说没有。请帮我查一下或者重新发货。"},
      {"from": "agent", "text": "您好，正在为您联系快递核实。"}
    ]
  },
  "order": {
    "id": "JD-8812",
    "amount_yuan": 239,
    "logistics": [
      {"time": "2026-09-22 18:05", "event": "派送中"},
      {"time": "2026-09-22 19:40", "event": "已签收，签收人：门卫"}
    ]
  },
  "policy": "因物流原因未收到货的，经核实后可补发或全额退款。"
}

这整个对象是一份状态，尽管里面有对话、订单和规则。当一个判断需要把几部分材料对照着看时（比如"签收记录是否与顾客描述矛盾"），就应该把它们放在一起。

把内容和问题分开 ​

状态只放内容与事实；问题描述你要模型对这些材料做出的判断。以上面的例子来说：留言、物流记录和退款规则放在状态里；"顾客是否要求补发""签收人是否可能不是顾客本人""规则是否支持退款"则写成问题。

这样分离的好处是：同一份状态可以挂上任意多的问题，而问题的措辞可以独立迭代、复用到其他状态上。

组织状态的几条建议 ​

  • 只放和问题相关的内容。 与判断无关的材料越多，越容易干扰模型，出错时也越难定位原因。能在代码里先过滤、先检索的，就先过滤（见 已知短板）。
  • 给字段起有意义的名字。 refund_policy 比 text2 好得多，模型会读字段名。
  • 用路径指向具体位置。 状态是嵌套对象时，在问题里用带反引号的路径指明要看的部分，例如 `ticket.messages[0].text`。见 原语总览。
  • 能用代码算的，先算好再放进去。 例如"距离签收已过去多少小时"，由代码计算后作为字段放进状态，比让模型比较两个时间戳可靠得多。
  • 把长文档切开。 状态加上最长的那个问题不能超过 32k token，而且状态越长、准确率越可能下降。长文档建议按段落或行切分后分批判断（见 合同条款逐行检索）。
  • 键的顺序无所谓。 JSON 对象会被序列化成文本交给模型，调换键的顺序不会带来实质影响。

延伸阅读 ​