Kimi K3 para sa Reasoning at Long-Horizon Agent: Mula sa Math Competitions hanggang sa Multi-Step Task Chains

Mahirap husgahan kung kayang magmaneho ng agent ang isang modelo mula sa leaderboard lamang — ang tunay na naghihiwalay ay ang katatagan sa isang multi-step task chain: unang hakbang tumawag ng tool, pangalawang hakbang tunawin ang resulta, pangatlong hakbang magpasya sa susunod. Kapag lumihis ang isang gitnang hakbang, bumibigay ang buong chain. Inilalagay ng opisyal na ulat ng Moonshot ang kimi-k3 bilang long-horizon flagship: sa 12 coding at agentic test na inilathala nila, tinalo ng modelo ang nakaraang henerasyon ng Claude flagship sa lahat, at ang matigas na pundasyon ng reasoning na GPQA 93.5% / AIME 91.2% ang nagpapanatiling mapagkakatiwalaan sa mga hatol sa gitna.

Bakit mahalaga ang kakayahang reasoning para sa mga agent

Ang puso ng isang agent ay ang model na nagpapasya sa sarili kung ano ang susunod na gagawin. Ang kalidad ng bawat desisyon ay nakasalalay sa pag-iisip sa kasalukuyang estado: pagkatapos basahin ang resulta ng tool, kailangan nitang husgahan kung itutuloy, uulitin, o papalitan ang direksyon. Ang mga benchmark tulad ng kompetisyong matematika at tanong-sagot sa agham antas-doktor ay sumusukat mismo sa ganitong multi-step reasoning — ang AIME 91.2% ay nangangahulugang kaya ng model ang mga gawaing mahaba ang chain na walang isang kawing na maaaring magkamali, at ang GPQA 93.5% ay nangangahulugang nananatiling matatag ang paghatol sa masalimuot na kaalaman sa domain.

Ang Artificial Analysis Intelligence Index, isang composite sa iba't ibang benchmark, ay nagbigay ng 57.1 — unang hanay ng mga open na modelo. Ang ibig sabihin ay hindi "kayang gawin lahat ng kimi-k3", kundi: bilang utak na gumagawa ng desisyon ng isang agent, pumasa ito, at kapag ipinares sa tool loop ay kayang bumataw ng totoong multi-step na trabaho.

Pinakamaliit na agent loop

Ang tool cycle sa format ng OpenAI ay may apat na bahagi: ilarawan ang mga tool → magpasyang tumawag ang model → isakatuparan at ibalik ang resulta → magpatuloy ang model mula sa resulta.

import json
import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["EXAIV_API_KEY"],
    base_url="https://exaiv.com/api/ai/v1",
)

tools = [
    {
        "type": "function",
        "function": {
            "name": "search_orders",
            "description": "Look up order status by order ID or customer name",
            "parameters": {
                "type": "object",
                "properties": {
                    "query": {"type": "string", "description": "Order ID or customer name"},
                },
                "required": ["query"],
            },
        },
    },
    {
        "type": "function",
        "function": {
            "name": "send_refund",
            "description": "Initiate a refund for a given order",
            "parameters": {
                "type": "object",
                "properties": {
                    "order_id": {"type": "string"},
                    "amount": {"type": "number"},
                },
                "required": ["order_id", "amount"],
            },
        },
    },
]

def execute_tool(name, args):
    if name == "search_orders":
        return {"order_id": "A1024", "status": "delivered_damaged", "amount": 129.0}
    if name == "send_refund":
        return {"ok": True, "refund_id": "R7788"}
    raise ValueError(f"unknown tool {name}")

messages = [{"role": "user", "content": "Customer says order A1024 arrived damaged. Handle it per policy."}]

for _ in range(10):  # hard cap to prevent infinite loops
    resp = client.chat.completions.create(
        model="kimi-k3",
        messages=messages,
        tools=tools,
    )
    msg = resp.choices[0].message
    if not msg.tool_calls:
        print(msg.content)  # final answer
        break
    messages.append(msg)
    for call in msg.tool_calls:
        args = json.loads(call.function.arguments)
        result = execute_tool(call.function.name, args)
        messages.append({
            "role": "tool",
            "tool_call_id": call.id,
            "content": json.dumps(result, ensure_ascii=False),
        })

Tumatakbo agad ang balangkas na ito. Sa tunay na sistema, palitan lamang ang execute_tool ng sarili mong API; ganap na standard ang protocol kaya't kumokonekta ang LangChain at LlamaIndex nang hindi binabago ang depinisyon ng tool.

Tatlong panuntunang inhinyeriya na nagpapanatili ng mahabang chain

Ang mataas na marka sa benchmark ay hindi katumbas ng katatagan sa production. Magdagdag mismo ng tatlong patong ng proteksyon:

Isa, isulat nang tumpak ang depinisyon ng tool. Ang field na description ang tanging batayan ng model sa pagpapasya kung gagamitin ang tool na iyon; ang malabong paglalarawan ay nagdudulot ng maling tawag. Ilarawan din ang format at kahulugan ng bawat parameter — ang depinisyon ng tool ang may pinakamataas na return on investment sa buong agent stack.

Dalawa, itala ang structured intermediate state pagkatapos ng bawat hakbang. Huwag hayaang mabuhay ang status ng gawain sa kasaysayan ng pag-uusap lamang. Pagkatapos ng bawat hakbang, isulat kung ano ang tapos na at ano ang susunod bilang structured record, upang makita ng model ang malinis na estado sa bawat desisyon sa halip na hinuha ito mula sa bunton ng diyalogo.

Tatlo, ang pagkabigo ay dapat makabawi. Maaaring mabigo ang pagtawag ng tool dahil sa timeout, maling argumento, o pagbabawal ng business rule. Kailangang hawakan ng loop ang tatlong uri: nabigo ang tool → ibalik ang error bilang tool message upang magpalit ng direksyon ang model; nabigo ang pag-parse ng output → ulitin na may corrective hint; naabot ang cap sa hakbang → itigil at mag-alert. Ang agent na walang rollback ay tiyak na babasag sa production, karaniwan sa kalagitnaan ng gabi.

Hugis ng state sa pagitan ng mga hakbang

Ang panuntunan sa state sa itaas ay nangangailangan ng konkretong anyo. Pagkatapos ng bawang tool cycle, idagdag ang isang maikling state block na mapagkakatiwalaan ng model:

def build_state_block(steps_done, pending, constraints):
    return (
        "CURRENT STATE:\n"
        + "\n".join(f"- done: {s}" for s in steps_done)
        + "\n".join(f"- pending: {p}" for p in pending)
        + "\nconstraints: " + constraints
    )

messages.append({
    "role": "user",
    "content": build_state_block(
        steps_done=["searched order A1024", "confirmed damaged delivery"],
        pending=["decide refund amount", "send refund", "notify customer"],
        constraints="refunds over 200 require human approval",
    ),
})

Nagkakahalaga ito ng ilang daang token bawat hakbang, at bumibili ng dalawang bagay: hindi na kailanman kailangang muling hanguin ng model ang posisyon nito mula sa raw na kasaysayan, at mababasa ng sarili mong monitoring ang state block upang malaman nang eksakto kung nasaan ang chain. Kapag lumihis ang isang run, ang state log ang iyong post-mortem.

Subukan ang ugali ng agent bago ang production

Sinusukat ng benchmark ang reasoning; ang iyong pipeline ay dapat sukatin ang iyong pipeline. Bago ilabas, i-replay ang isang nakatakdang evaluation set:

• Golden tasks: sampu hanggang dalawampung totoong task chain na may alam na tamang resulta, patakbuhin sa bawat pagbabago ng model o prompt
• Adversarial na resulta ng tool: i-replay nang nagbabalik ang mga tool ng error, walang laman, at malformed na data — tiyaking nagpapalit ng direksyon ang model sa halip na mag-imbento ng tagumpay
• Rate ng pagtama sa cap: bilangin kung gaano kadalas humahampas ang mga run sa cap ng hakbang; ang tumataas na rate ay nangangahulugang kailangang ayusin ang depinisyon ng tool o ang pag-frame ng gawain
• Gastos bawat natapos na gawain: kabuuang token hinati sa matagumpay na run — ang numerong nagpapasya kung karapat-dapat ang agent na ito sa production

Isang hapon lang ang pagbuo ng harness na ito at nahuhuli nito ang karamihan ng insidente bago maranasan ng mga user.

Mag-route ayon sa hugis ng gawain

Mas mainam pumili ayon sa hugis ng gawain kaysa ayon sa leaderboard:

Ang hybrid orchestration ang karaniwang anyo: ang mabilis na tier ay humahawak sa mataas-na-frequency na mekanikal na gawain, ang kimi-k3 ay kumukuha sa kumplikadong chain. Iisang key, iisang endpoint.

Tiered routing sa loob ng iisang chain

Ang totoong agent chain ay may halong madali at mahirap na hakbang, at ang paggastos ng flagship sa bawat hakbang ay nag-aaksaya ng pera at latency. Ang isang tiered router sa loob ng loop ay nagpapanatili ng kalidad kung saan ito mahalaga:

def route_step(step):
    if step["kind"] in ("decide", "synthesize", "verify"):
        return "kimi-k3"          # judgment steps: flagship reasoning
    return "deepseek-v4.1-flash-1017"   # mechanical steps: lookup, format, classify

Ang mga judgment step — pagpapasya sa susunod, pagsasama-sama ng magkasalungat na resulta ng tool, pag-verify ng kandidatong sagot — ang lugar kung saan talaga nagbabayad ang reasoning benchmarks. Ang mga mekanikal na hakbang (reformatting, klasipikasyon, tuwirang lookup) ay maayos na tumatakbo sa mabilis na tier. Karaniwang nakikita ng mga team na nakararami sa mga hakbang ay napupunta sa mekanikal na balde, kaya malaki ang natitipid ng tiering habang nananatiling nakaangkla sa flagship ang kalidad ng desisyon ng chain. Parehong endpoint at key ang naglilingkod sa dalawang modelo; ang model field lamang ang nagbabago.

Observability para sa mga agent run

Kapag tumatakbo na ang mga chain sa production, halos lahat ng tanong sa insiden ay sinasagot ng tatlong log:

• Decision log: isang linya bawat loop iteration — numero ng hakbang, napiling modelo, tool na tinawag, token na nagamit
• State log: ang structured state block mula sa bawat hakbang, kaya ang isang nabigong run ay maaaring i-replay mula sa eksaktong punto ng paglihis
• Cost log: token bawat run na ina-aggregate ayon sa uri ng gawain — ito ang paraan upang mapansin na ang isang workflow ay tahimik na kumukonsumo ng kalahati ng iyong badyet

Panatilihin ang mga ito sa iisang trace ID upang ang isang nabigong run ay mabuo muli mula simula hanggang wakas. Ang pag-debug ng agent nang wala ang mga log na ito ay nagiging hulaan; sa mga ito, karamihan ng insiden ay dalawang minuto lamang ng pagbabasa.

FAQ

Ano ang sinasagot ng artikulong ito

• paano gumawa ng agent gamit ang kimi-k3
• paano sumulat ng tool loop
• paano mabawi ang agent mula sa failure

Mabilisang mapa ng senaryo

Tumingin sa hinaharap

Nagpapatuloy na nagbabago ang catalog at mga weights; ang mga integration at calling convention dito ay sumusunod sa opisyal na dokumento sa oras ng paglalathala.

Mga pinagmulan at beripikasyon

Ang mga pangunahing katotohanan sa artikulong ito ay mula sa opisyal na ulat ng Kimi at EXAIV function-calling documentation at na-verify noong 2026-11-09. Ang model ID, presyo at availability ay sumusunod sa live catalog ng platform — sinadyang walang nakapirming numerong mabilis mals. Ang mga sample code ay sumusunod sa API contract sa oras ng paglalathala; tingnan ang opisyal na dokumento bago ikonekta sa production.

Saklaw at audience

Audience: mga developer na bumubuo ng multi-step na agent. Saklaw: tool loop, state management, at failure recovery. Hindi saklaw: pagkukumpara ng benchmark o pagsasanay ng modelo.

Tala ng patnugot at pagwawasto

Isinulat ng EXAIV content team mula sa mga mapapatunayang katotohanan, na may sinusuri na mga pinagmulan at code bago ilathala. Kung may luma o mali, ang opisyal na release page at live catalog ang batayan — magbigay-alam sa feedback channel ng page para maayos namin ito.

Kaugnay na babasahin

• Gabay sa Kimi K3
• Gabay sa Function Calling
• Gabay sa agent framework
• Error handling at retry
• Checklist bago ang production