No.02RelationHuman ↔ Human / Agent ↔ AgentUpdated2026-09-21Read2 分钟

多个 Agent 上场后，责任不会自动出现。

Concordry 让我们看见，分配角色只是协作的起点。交接什么、谁能决定、由谁验收，才决定工作是否真的向前。

来自 Concordry 的任务、角色、授权、交付与验收设计。当前为本地工程 Alpha，尚不能据此判断真实团队的规模化使用效果。

01多一个角色，也多一次交接

给几个 Agent 分别安排研究、执行和复核，乍看已经有了一个团队。可只要追问一次“现在谁负责”，事情就会变得具体：研究结束的条件是什么？执行者能不能修改研究结论？复核发现问题时，工作应该退回给谁？

在 Concordry 中，我们把角色、任务、交付与验收放进同一个上下文。原因很直接：如果只能看到各自的输出，就很难知道工作卡在何处，也很难接着做。一个交付需要带上来路、限制和未解决的问题，接手者才不必重新猜一遍。

02Agent 之间的关系，背后仍然有人

不同 Agent 可能属于不同的人，使用不同的资料，也承担不同范围的授权。两个 Agent 能交换消息，并不表示它们就可以共享全部上下文，更不表示一方能替另一方作决定。

这让“人与人”的关系重新回到技术系统里。人之间对目标的理解是否一致，是否同意披露一份资料，谁愿意为某个结果负责，会通过 Agent 的行动被放大。协作层必须容纳这些差异。

我们在 Concordry 中保留独立身份、所有者与私域边界，并区分执行者和验收者。这些设计不能保证每次协作都顺利，但能让发生的问题有地方被看见、被退回、被重新判断。

03组织设计会成为产品的一部分

一次技术调用可以用输入、输出和错误码描述；一项共同工作还涉及优先级、分歧和责任。系统越能行动，这一层越不能只靠用户在旁边记住。

我们的判断是，多 Agent 产品需要同时回答两类问题：信息如何流动，以及决定如何成立。前者关心上下文和协议，后者关心谁有权批准、谁可以提出异议、什么证据足以支持完成。

我们也保留一个疑问：显式规则会不会让简单工作变得太重？因此，协作结构应当随任务变化。一个人的短任务不必套用完整组织流程；跨角色、跨所有者的工作，则需要更清楚的交接和责任。