How we moved our agents from personal terminals into team channels
In six months, a team of under ten went from editor autocomplete to about thirty agents with standing jobs, from cluster checks and code review to releases, fork maintenance and customer support, plus the permissions and context sharing around them.
Over the past few months, AI has fundamentally changed how our team works. Much of our recurring work is now genuinely automated by agents: the daily cluster inspection and alert analysis, pull request review, maintenance of an upstream fork, release notes, and answering questions in customer groups. We are an engineering team of fewer than ten people.
A year ago
A year ago, "using AI" meant an editor with AI in it: completions, rewriting a function, explaining unfamiliar code. Everyone used it, and nothing about how the team worked changed. The output was still a diff on someone's machine. Nobody else saw the conversation, and there was nothing in it worth seeing.
We did not build anything around it. The models were not yet at the point where you could hand them a task and walk away.
The turning point was Claude Opus 4.6. It was the first model we used that was worth building around: give it a task and it runs commands, reads the results and keeps going. Within weeks Claude Code and Codex were everyone's daily tools.
Then people started giving them work other than code. A production error: let an agent take the first look. An upstream release: let an agent upgrade our fork. Inspect the cluster every morning. Take customer questions. Within a month every engineer had accumulated a pile of their own glue: shell scripts, cron entries, a bot token in a dotfile, a prompt that stitched together the context the agent needed.
Two problems
The first was duplication. When we compared what each of us had written, it was nearly the same: how messages get in and out, how to schedule, where credentials live, how to assemble context. Everyone had done it once, and each copy only ran on its owner's machine.
The second was lost context. The most useful part of a session is usually not the final diff but the process in the middle: what was tried, what failed, why this fix over that one, which dashboard had the answer. All of it sat in one person's terminal and was gone when the session ended. When someone else needed it, the only way to get it was a meeting.
Two weeks of Slack bots
In June we tried the most direct approach: a set of Slack bots built on the open-source OpenACP, changed so that each thread in an existing channel became one session.
Someone mentioned an agent in an incident thread, the rest of the team watched what it was checking, and asked follow-up questions in the same thread. Colleagues outside engineering started using the bots too; a mention in Slack is all it takes.
Then came two weeks of patches, all about threads: carrying the earlier thread into a mid-thread mention, backfilling messages the bot had missed, stopping bots from triggering each other in a loop. The software had no concept of "a conversation with several people and several bots in it", and we were bolting one on.
- One platform app with several agents behind it, instead of one process, one Slack app and one set of tokens per bot
- Separate identities for several users, instead of one shared login on one machine
- A real control plane, instead of a bot that ran operational shell commands from the chat
- Versioned daemons with controlled upgrades
- Sessions that survive a restart, each with its own workspace, instead of one directory shared by every thread
- Conversations and threads as core concepts, not adapter patches
We also tried replacing the whole thing with Hermes. Its demo covered most of what we wanted: loops, proactive messages, a kanban board and memory, all built in. We moved a rebase bot onto it and ran it for a day. The biggest problem was that it had no team layer: who may use which agent, who may see its sessions, which repositories and tools an agent may touch. There was no permission model; the whole thing assumed one user. Beyond that, its own harness and Claude Code ran interleaved inside one task, and without the coding agent's cache and resume, every turn re-sent the full context, so latency and cost were both high. When something failed, we could not tell which layer had failed. This describes the version we tried at the time; Hermes has changed a great deal since.
Two decisions from that time have not changed: permissions are part of the platform, not a feature to add later; and we keep the harness engineers already run locally, so that any behaviour seen in a channel can be reproduced in a terminal.
We built the connecting layer ourselves, on ACP, and open-sourced it a month later as AgentConnect.
What the agents do now
The production organization was created on a Sunday in July. By Tuesday six agents were running, the same jobs people had been running from personal scripts, now each with a name, a channel and a machine. Today:
- About thirty agents: one generalist, the rest specialists
- Running on seven of our own machines plus a managed pool
- Connected to Slack, Telegram, Discord and Linear
- Twenty-odd scheduled jobs
The generalist is connected to the development channel, direct messages and Linear. It can check out the team's repositories on demand, and anyone can mention it. Small changes are done right in the Slack thread: describe the problem, it edits the code, opens a pull request and runs the checks, and a person glances at it in the thread and merges, without opening a terminal.
Each specialist owns one kind of work, with its own repositories, tools, channels and schedules, and permissions scoped to that work.
!The agent list in the console: each agent's runtime and model, the machine it runs on, and its repositories and integrations. Agent and repository names replaced with example values
Design documents and meetings. One agent owns documentation. Design discussions mention it in the development channel; it reads the current system and the existing design documents and proposes a path, colleagues add constraints in the thread, and it revises. Once the discussion settles, it opens a pull request that writes the conclusion into the matching design document under docs/, reviewed together with the implementation. Every meeting is transcribed. We do not use the transcription service's own summaries; the raw transcript goes into a separate repository, the agent writes the summary there, and then updates the related issues and design documents in the other repositories.
The documentation repository is organized by project, and each project has two parts, design documents and meetings:
agentconnect/
├── design-docs/ # reviewed as PRs
│ ├── agents-collaboration-design.md
│ └── daemon-centric-architecture.md
└── meetings/ # one pair per meeting
├── 2026-06-12-agents-collaboration-kickoff.txt # raw transcript
└── 2026-06-12-agents-collaboration-kickoff-summary.md # written by the agent
Inspection and alerts. One agent walks the cluster every morning and posts a report to the alerts channel. A few others each watch one class of service in a business area for latency and versions. When an alert lands in the channel, the on-call agent picks it up in the same thread: it checks Grafana metrics, looks at pods and logs, and compares against recent changes in the repository. Kubernetes and Grafana are MCP services, registered once at the organization level and enabled per agent. How each class of event should be handled is written as a skill in the repository: which metrics to check first, the common causes, what it may handle on its own and when it must call a person. When the procedure changes, the skill changes, and every on-call agent uses the new one from the next run. Whether it is an incident is the engineer's call.
Cross-model code review. Every pull request gets a first pass from the review bot, which leaves inline comments and posts its own check. The same review bot can switch runtime and model per pull request, and different models notice different things. Running on Codex, it reproduced a bug in one pull request: editing a scheduled task's time before saving dropped the saved task's identity. It requested changes, and approved once the fix landed. Running on Claude, it approved another pull request and listed exactly what it had not verified and was leaving to CI. For a deeper look, someone mentions a reviewer on a stronger model.
!The same review bot: running on Codex above, requesting changes; running on Claude below, approving and listing what it did not verify
Releases. Every merge to main produces a release candidate; a stable release points the release branch at a chosen commit. What happens after the release is the agent's job: confirm the release succeeded, read the pull requests between the two stable versions, group related pull requests into one feature entry, call out behaviour changes and upgrade notes separately, write that as the Summary at the top of the release page, and then comment on and close each issue the release fully fixed. The Summary on v2.8.0 came from this; the Features list below it is the generated changelog. The procedure is a skill, so the rules are the same whichever agent runs it.
The upstream fork. We maintain a fork of an upstream runtime adapter: the upstream tag plus a pile of our own patches. The patches carry logic, so when upstream refactors, the job is not resolving a few lines of conflict. It is understanding what upstream changed and what our patch was for, then re-implementing the intent on the new base. The whole thing goes to a coding agent: an upstream release or a schedule starts it, it reads both sides' changes, decides which patches are still needed, which upstream has absorbed and can be dropped, and which need rewriting, makes the changes in its own worktree, runs typecheck, tests and build, opens a pull request, and posts what needs a human judgement to the channel. That repository now has fourteen rebase branches, one per upstream version, with the check results beside each. Merging and publishing are done by a person.
!The rebase pull request the agent opened on the fork: which upstream changes it kept, how it adjusted each patch, which checks it ran, and the linked pull request that bumps the pin in the product repository
Customer group support. A support agent answers questions in customers' Telegram groups and escalates what it cannot answer to an engineering channel in Slack. The groups get a lot of spam, so each message is scored first; only messages under the threshold reach the support agent, and the rest go to a moderator agent. Replies about a specific account are confirmed by a person before they go out.
!The support agent hands a payment incident to the payments agent in Slack; the payments agent reproduces it and opens a pull request with the fix
The generalist can reach many repositories and sits in public channels, private channels and direct messages at once, so permissions cannot be skipped. We handle them in three layers.
The agent itself: who may change its configuration, which repositories and tools it may touch, who may use it in which channels, and which agents may call it or be called by it, each set separately.
Sessions: who may read a session follows the membership of the place the conversation happened. A session in a private channel is readable only by people currently in that channel; whoever leaves the channel can no longer read it. Direct messages stay private. There is no separate list to maintain.
!Session access in the organization settings: three switches make session visibility follow Slack, GitHub or Feishu/Lark membership
Memory is layered by where the conversation happened: what was said somewhere is remembered there. What an agent learns in a public channel goes into the shared layer, a private or external group gets its own layer, and a direct message gets that person's layer. When it answers, the agent loads only the memory the current conversation is allowed to read.
Operations that need approval send an approval card by direct message to the agent's editors, rather than letting anyone in the channel approve.
Where the context lives
What an agent produces has to be kept somewhere the team and the other agents can find later, with access still controlled by where it came from.
Design documents live in the same repository as the code, under docs/, with implementation status and links to issues and pull requests. The project instructions file says where the documents are and that a change to a design and its implementation go in the same pull request. The product repository has gone from 35 design documents at open-sourcing to 100 now. A reviewer reads the linked design document directly instead of asking the author to explain it in a meeting. Anything beyond a single repository, runbooks and architecture decisions, goes into the organization's knowledge library: owners publish it, it is versioned, and agents look it up on demand.
How to handle a class of alert, how to write a release description, how to rebase the fork: each is a skill file, imported once and enabled per agent. Once, after the agent that checks the price list every day posted its report, a colleague asked in the thread whether it had failed to find the matching skill. It confirmed it had not found it and had instead done a read-only comparison following the channel's earlier practice. The colleague pointed out the skill was in the repository. The agent found it, confirmed its earlier search had skipped hidden directories by default, and recorded the problem in its working conventions for later runs.
An agent's workspace is a Git repository, so what one agent writes, any agent's next session can read; the daemons on colleagues' own machines use the same repositories. Tickets are maintained by the agent doing the work: updated as it progresses, closed when done, linked to the documents and pull requests.
The local Claude Code and Codex memory mechanism is unchanged; we only point the memory directory at a Git repository, with hooks that pull at session start and push at session end, so it is the same memory across machines and harnesses. The platform agents' memory is a separate system, layered by conversation source as described above. Merging the two is something we may do later.
What's next
Today's agents are triggered by a mention, a schedule, a pull request or issue event, a webhook, or a judgement (is this spam, which agent should take it), and they do the one thing the trigger specifies.
Proactive agents. Make the agent more like a teammate: it checks the things it is responsible for and proposes before acting. For example, it notices that a just-merged pull request changed behaviour and the matching design document was not updated, and proposes a documentation pull request in the development channel; or the same question has come up three times this week in a customer group, and it proposes writing the answer into the docs. It acts only once a person approves. This is in preview.
Computer use. Some things have no API, only a desktop app or a browser. Register a machine as a Computer, grant it to specific agents, and they can take screenshots, click and type; a person watches the live screen in the console and can take over at any time. Also in preview.
Joining meetings. Today a meeting is recorded, transcribed and processed afterwards by the documentation agent. Further out, the agent joins the meeting as a participant: it can be asked questions during the meeting, and decisions get written back to design documents and issues on the spot rather than afterwards. This has not started.
AgentConnect is open source under Apache 2.0 and deploys with Docker Compose or Kubernetes. If you hit a problem, open an issue; if you find it useful, you are welcome to star the repository.
agentconnect-md/agentconnect
docs.agentconnect.md
Mentions
How we moved our agents from personal terminals into team channels In six months, a team of under ten went from editor autocomplete to about thirty agents with standing jobs, from cluster checks and code review to releases, fork maintenance and customer support, plus the permissions and context sharing around them. Over the past few months, AI has fundamentally changed how our team works. Much of our recurring work is now genuinely automated by agents: the daily cluster inspection and alert analysis, pull request review, maintenance of an upstream fork, release notes, and answering questions in customer groups. We are an engineering team of fewer than ten people. A year ago A year ago, "using AI" meant an editor with AI in it: completions, rewriting a function, explaining unfamiliar code. Everyone used it, and nothing about how the team worked changed. The output was still a diff on someone's machine. Nobody else saw the conversation, and there was nothing in it worth seeing. We did not build anything around it. The models were not yet at the point where you could hand them a task and walk away. The turning point was Claude Opus 4.6. It was the first model we used that was worth building around: give it a task and it runs commands, reads the results and keeps going. Within weeks Claude Code and Codex were everyone's daily tools. Then people started giving them work other than code. A production error: let an agent take the first look. An upstream release: let an agent upgrade our fork. Inspect the cluster every morning. Take customer questions. Within a month every engineer had accumulated a pile of their own glue: shell scripts, cron entries, a bot token in a dotfile, a prompt that stitched together the context the agent needed. Two problems The first was duplication. When we compared what each of us had written, it was nearly the same: how messages get in and out, how to schedule, where credentials live, how to assemble context. Everyone had done it once, and each copy only ran on its owner's machine. The second was lost context. The most useful part of a session is usually not the final diff but the process in the middle: what was tried, what failed, why this fix over that one, which dashboard had the answer. All of it sat in one person's terminal and was gone when the session ended. When someone else needed it, the only way to get it was a meeting. Two weeks of Slack bots In June we tried the most direct approach: a set of Slack bots built on the open-source OpenACP, changed so that each thread in an existing channel became one session. Someone mentioned an agent in an incident thread, the rest of the team watched what it was checking, and asked follow-up questions in the same thread. Colleagues outside engineering started using the bots too; a mention in Slack is all it takes. Then came two weeks of patches, all about threads: carrying the earlier thread into a mid-thread mention, backfilling messages the bot had missed, stopping bots from triggering each other in a loop. The software had no concept of "a conversation with several people and several bots in it", and we were bolting one on. - One platform app with several agents behind it, instead of one process, one Slack app and one set of tokens per bot - Separate identities for several users, instead of one shared login on one machine - A real control plane, instead of a bot that ran operational shell commands from the chat - Versioned daemons with controlled upgrades - Sessions that survive a restart, each with its own workspace, instead of one directory shared by every thread - Conversations and threads as core concepts, not adapter patches We also tried replacing the whole thing with Hermes. Its demo covered most of what we wanted: loops, proactive messages, a kanban board and memory, all built in. We moved a rebase bot onto it and ran it for a day. The biggest problem was that it had no team layer: who may use which agent, who may see its sessions, which repositories and tools an agent may touch. There was no permission model; the whole thing assumed one user. Beyond that, its own harness and Claude Code ran interleaved inside one task, and without the coding agent's cache and resume, every turn re-sent the full context, so latency and cost were both high. When something failed, we could not tell which layer had failed. This describes the version we tried at the time; Hermes has changed a great deal since. Two decisions from that time have not changed: permissions are part of the platform, not a feature to add later; and we keep the harness engineers already run locally, so that any behaviour seen in a channel can be reproduced in a terminal. We built the connecting layer ourselves, on ACP, and open-sourced it a month later as AgentConnect. What the agents do now The production organization was created on a Sunday in July. By Tuesday six agents were running, the same jobs people had been running from personal scripts, now each with a name, a channel and a machine. Today: - About thirty agents: one generalist, the rest specialists - Running on seven of our own machines plus a managed pool - Connected to Slack, Telegram, Discord and Linear - Twenty-odd scheduled jobs The generalist is connected to the development channel, direct messages and Linear. It can check out the team's repositories on demand, and anyone can mention it. Small changes are done right in the Slack thread: describe the problem, it edits the code, opens a pull request and runs the checks, and a person glances at it in the thread and merges, without opening a terminal. Each specialist owns one kind of work, with its own repositories, tools, channels and schedules, and permissions scoped to that work. !The agent list in the console: each agent's runtime and model, the machine it runs on, and its repositories and integrations. Agent and repository names replaced with example values Design documents and meetings. One agent owns documentation. Design discussions mention it in the development channel; it reads the current system and the existing design documents and proposes a path, colleagues add constraints in the thread, and it revises. Once the discussion settles, it opens a pull request that writes the conclusion into the matching design document under docs/, reviewed together with the implementation. Every meeting is transcribed. We do not use the transcription service's own summaries; the raw transcript goes into a separate repository, the agent writes the summary there, and then updates the related issues and design documents in the other repositories. The documentation repository is organized by project, and each project has two parts, design documents and meetings: agentconnect/ ├── design-docs/ # reviewed as PRs │ ├── agents-collaboration-design.md │ └── daemon-centric-architecture.md └── meetings/ # one pair per meeting ├── 2026-06-12-agents-collaboration-kickoff.txt # raw transcript └── 2026-06-12-agents-collaboration-kickoff-summary.md # written by the agent Inspection and alerts. One agent walks the cluster every morning and posts a report to the alerts channel. A few others each watch one class of service in a business area for latency and versions. When an alert lands in the channel, the on-call agent picks it up in the same thread: it checks Grafana metrics, looks at pods and logs, and compares against recent changes in the repository. Kubernetes and Grafana are MCP services, registered once at the organization level and enabled per agent. How each class of event should be handled is written as a skill in the repository: which metrics to check first, the common causes, what it may handle on its own and when it must call a person. When the procedure changes, the skill changes, and every on-call agent uses the new one from the next run. Whether it is an incident is the engineer's call. Cross-model code review. Every pull request gets a first pass from the review bot, which leaves inline comments and posts its own check. The same review bot can switch runtime and model per pull request, and different models notice different things. Running on Codex, it reproduced a bug in one pull request: editing a scheduled task's time before saving dropped the saved task's identity. It requested changes, and approved once the fix landed. Running on Claude, it approved another pull request and listed exactly what it had not verified and was leaving to CI. For a deeper look, someone mentions a reviewer on a stronger model. !The same review bot: running on Codex above, requesting changes; running on Claude below, approving and listing what it did not verify Releases. Every merge to main produces a release candidate; a stable release points the release branch at a chosen commit. What happens after the release is the agent's job: confirm the release succeeded, read the pull requests between the two stable versions, group related pull requests into one feature entry, call out behaviour changes and upgrade notes separately, write that as the Summary at the top of the release page, and then comment on and close each issue the release fully fixed. The Summary on v2.8.0 came from this; the Features list below it is the generated changelog. The procedure is a skill, so the rules are the same whichever agent runs it. The upstream fork. We maintain a fork of an upstream runtime adapter: the upstream tag plus a pile of our own patches. The patches carry logic, so when upstream refactors, the job is not resolving a few lines of conflict. It is understanding what upstream changed and what our patch was for, then re-implementing the intent on the new base. The whole thing goes to a coding agent: an upstream release or a schedule starts it, it reads both sides' changes, decides which patches are still needed, which upstream has absorbed and can be dropped, and which need rewriting, makes the changes in its own worktree, runs typecheck, tests and build, opens a pull request, and posts what needs a human judgement to the channel. That repository now has fourteen rebase branches, one per upstream version, with the check results beside each. Merging and publishing are done by a person. !The rebase pull request the agent opened on the fork: which upstream changes it kept, how it adjusted each patch, which checks it ran, and the linked pull request that bumps the pin in the product repository Customer group support. A support agent answers questions in customers' Telegram groups and escalates what it cannot answer to an engineering channel in Slack. The groups get a lot of spam, so each message is scored first; only messages under the threshold reach the support agent, and the rest go to a moderator agent. Replies about a specific account are confirmed by a person before they go out. !The support agent hands a payment incident to the payments agent in Slack; the payments agent reproduces it and opens a pull request with the fix The generalist can reach many repositories and sits in public channels, private channels and direct messages at once, so permissions cannot be skipped. We handle them in three layers. The agent itself: who may change its configuration, which repositories and tools it may touch, who may use it in which channels, and which agents may call it or be called by it, each set separately. Sessions: who may read a session follows the membership of the place the conversation happened. A session in a private channel is readable only by people currently in that channel; whoever leaves the channel can no longer read it. Direct messages stay private. There is no separate list to maintain. !Session access in the organization settings: three switches make session visibility follow Slack, GitHub or Feishu/Lark membership Memory is layered by where the conversation happened: what was said somewhere is remembered there. What an agent learns in a public channel goes into the shared layer, a private or external group gets its own layer, and a direct message gets that person's layer. When it answers, the agent loads only the memory the current conversation is allowed to read. Operations that need approval send an approval card by direct message to the agent's editors, rather than letting anyone in the channel approve. Where the context lives What an agent produces has to be kept somewhere the team and the other agents can find later, with access still controlled by where it came from. Design documents live in the same repository as the code, under docs/, with implementation status and links to issues and pull requests. The project instructions file says where the documents are and that a change to a design and its implementation go in the same pull request. The product repository has gone from 35 design documents at open-sourcing to 100 now. A reviewer reads the linked design document directly instead of asking the author to explain it in a meeting. Anything beyond a single repository, runbooks and architecture decisions, goes into the organization's knowledge library: owners publish it, it is versioned, and agents look it up on demand. How to handle a class of alert, how to write a release description, how to rebase the fork: each is a skill file, imported once and enabled per agent. Once, after the agent that checks the price list every day posted its report, a colleague asked in the thread whether it had failed to find the matching skill. It confirmed it had not found it and had instead done a read-only comparison following the channel's earlier practice. The colleague pointed out the skill was in the repository. The agent found it, confirmed its earlier search had skipped hidden directories by default, and recorded the problem in its working conventions for later runs. An agent's workspace is a Git repository, so what one agent writes, any agent's next session can read; the daemons on colleagues' own machines use the same repositories. Tickets are maintained by the agent doing the work: updated as it progresses, closed when done, linked to the documents and pull requests. The local Claude Code and Codex memory mechanism is unchanged; we only point the memory directory at a Git repository, with hooks that pull at session start and push at session end, so it is the same memory across machines and harnesses. The platform agents' memory is a separate system, layered by conversation source as described above. Merging the two is something we may do later. What's next Today's agents are triggered by a mention, a schedule, a pull request or issue event, a webhook, or a judgement (is this spam, which agent should take it), and they do the one thing the trigger specifies. Proactive agents. Make the agent more like a teammate: it checks the things it is responsible for and proposes before acting. For example, it notices that a just-merged pull request changed behaviour and the matching design document was not updated, and proposes a documentation pull request in the development channel; or the same question has come up three times this week in a customer group, and it proposes writing the answer into the docs. It acts only once a person approves. This is in preview. Computer use. Some things have no API, only a desktop app or a browser. Register a machine as a Computer, grant it to specific agents, and they can take screenshots, click and type; a person watches the live screen in the console and can take over at any time. Also in preview. Joining meetings. Today a meeting is recorded, transcribed and processed afterwards by the documentation agent. Further out, the agent joins the meeting as a participant: it can be asked questions during the meeting, and decisions get written back to design documents and issues on the spot rather than afterwards. This has not started. AgentConnect is open source under Apache 2.0 and deploys with Docker Compose or Kubernetes. If you hit a problem, open an issue; if you find it useful, you are welcome to star the repository. agentconnect-md/agentconnect docs.agentconnect.md
群里接了几个 Agent 之后，我们是怎么决定「它该不该说话」的 最近做的一个东西，顺手记一下思路，可能对也在折腾 Agent 的人有点用。 背景是这样：我们把几个 coding agent 接进了团队的 Slack 和 GitHub 。接进去之后很快发现一个问题——Agent 不知道什么时候该闭嘴。一个支持频道里，有人提问，有人贴报错，也有人回一句「好的谢谢」。如果每条都回，很快就没人愿意把它留在群里了。 最早的做法是最直觉的那种：把消息丢给大模型，问它「这条需要回复吗」，再解析返回值。能用，但有两个地方一直别扭： - 每条进来的消息都要走一次完整的模型调用，延迟是用户能感觉到的。 - 模型偶尔会很热情地解释它为什么这么判断，而不是老实返回我们要的那个值，于是我们得在返回里做字符串处理。 后来换了个思路：这种判断其实不需要「生成」，只需要「判断」。现在这部分交给 TypeSafe 的 Jev 来做——定义一个问题和判定标准，它返回一个带概率的类型化结果，路由逻辑写在我们自己的代码里，而不是写在 prompt 里。 这个区别比我原本以为的重要。想调「多严才回复」的时候，改的是一个阈值数字，而不是去改 prompt 里的一句话——后者经常会顺带影响到别的三个地方。 目前用在这几处： - 判断一条消息要不要回； - 新对话分流，技术问题给工程 Agent ，账单问题给支持 Agent ； - 新会话启动时选模型。有个我们自己觉得挺好玩的用法：按 PR 作者分配审查者，Claude 写的让 Codex 审，Codex 写的让 Claude 审。 也有不适合用的地方，这部分可能更有参考价值： - 需要把判断理由讲给人听的场景。概率分布不是解释，人被判错的时候想要的是理由。 - 真的需要多步推理的判断。官方文档建议拆成多个原子问题再在代码里组合，这个建议是对的，但有时候老实承认「这里就是需要推理」，直接调大模型更合适。 - 判定标准本身就说不清楚的场景。问题问得很干脆、标准却含糊，比 prompt 还糟，因为它看起来很严谨。 不打算说这个思路有多新。「这不就是分类器套了层好用的接口吗」——这个说法我觉得没错。对我们来说有价值的恰恰是那层接口：不用自己训练、自己部署、自己维护，定义完能先拿样例跑一遍再上线。 写得细一些的版本在这里，有截图： agentconnect.md 仓库： agentconnect-md/agentconnect （利益相关：AgentConnect 是我们自己做的开源项目，这里不展开介绍，只是说明一下背景。）