[Question] How should we build a durable agent with a long conversation and many tool calls per turn?
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Tài liệu
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- python
- Lĩnh vực
- backend, distributed-systems
Hướng nghiên cứu
Start with the temporalio.contrib.openai_agents integration and the External Storage setting, especially payload_size_threshold, using the reported history and payload limits as the investigation context. Review the documented limits and workflow patterns, then define what guidance is needed for long conversations, many tool calls, external storage, and one-workflow-per-turn designs.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
What we're building
A chat app on temporalio.contrib.openai_agents. One user turn can make up to about 100 tool calls before the agent writes its final answer, and conversations grow to 100k–200k tokens.
We send our requests to LLM providers that don't support OpenAI's conversation chaining, so we can't use previous_response_id or conversation_id. Parallel tool calling also isn't reliable across the models we use.
We couldn't find guidance for this setup, and we'd rather ask than guess, because when it breaks the server kills the whole workflow partway through a turn.
What we saw
Because every model call sends the whole conversation again plus all the tool calls and results so far, and each of those is recorded as an activity input, history grows fast. On temporalio 1.33.0 and openai-agents 0.19.4, model call inputs were 99.8% of the workflow history in every run we did.
History grows roughly like N*B + G*N*(N-1)/2, where N is the number of model calls, B is the size of the conversation, and G is how much each tool call adds.
| conversation | tool output | model calls reached | history | what happened |
|---|---|---|---|---|
| ~209k tok | 5 KB | 53 of 100 | 50.48 MB | TerminatedError: Workflow history size exceeds limit. |
| ~105k tok | 5 KB | 82 of 100 | 50.33 MB | killed |
| ~105k tok | 4 KB | 86 of 100 | 50.15 MB | killed |
| ~105k tok | 1 KB | 101 | 47.49 MB | finished |
| ~209k tok | 5 KB + external storage | 101 | 0.12 MB | finished (108 MB went to the blob store) |
The numbers lined up with what we put in — for a 800 KB conversation we measured 842.2 KB per call, and for 5 KB tool outputs we measured 5.08 KB of growth per call. Our math said the first run would run out of room at call 53, and the server killed it at call 53.
If we push the conversation bigger, what breaks first changes. Above roughly 450k tokens it stops being the 50 MB history limit and becomes the 2 MiB limit on a single payload. Around 522k tokens a single model call's input is too big to send at all, so the turn fails on the first call.
Questions
-
How big can the conversation be, and how many tool calls can one turn make? We worked out our own numbers by measuring, but we don't know if we're measuring the right thing, or if there's a way to avoid sending the conversation again on every call that we've missed. This might be the agent version of what temporalio/ai-cookbook#32 is asking for.
-
Is External Storage the answer here? Turning it on fixed our case completely — history went from 50.48 MB to 0.12 MB. Is it the recommended fix for agents, and is there advice on what to set
payload_size_thresholdto? It's still marked experimental, so we'd like to know if it's considered ready for this. -
Should each user turn be its own workflow? We moved to one workflow per turn, keeping the conversation in our own database and passing it in as workflow input, because we couldn't see how to stop history growing if one workflow handles every turn. Is that the pattern you'd recommend, or have we misread it?
- Ngôn ngữ chính
- Python
- Star
- 1.2k
- Fork
- 241
- Merge trung bình
- 3 ngày 2 giờ
- Pull request đã merge (30 ngày)
- 49
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của temporalio/sdk-python
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
temporalio/sdk-python#1517 · 10 bình luận ·
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
temporalio/sdk-python#496 ·
-
[Bug] Local activity resolutions regrouped on replay since 1.32.0, delivering the wrong payload Đang mở
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 52/100
temporalio/sdk-python#1881 · 1 bình luận ·
-
bug
temporalio/sdk-python#1817 · 1 bình luận · 1 người được giao ·
-
Cloud CI Skips Nexus Tests Đang mở
temporalio/sdk-python#1704 · 1 người được giao ·
Tất cả issue của temporalio/sdk-python
Issue tương tự
-
documentation help wanted
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
simonw/sqlite-utils#872 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100